Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Enhanced Export Control of Cryptographic Keys via a Control Vector

IP.com Disclosure Number: IPCOM000107962D
Original Publication Date: 1992-Apr-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 4 page(s) / 210K

Publishing Venue

IBM

Related People

Le, AV: AUTHOR [+3]

Abstract

This article describes a method of enhanced export/import control of cryptographic keys via a control vector-based key management. The method is such that a key generated at a sending device for export to a receiving device is prevented from being re-imported at the generating device. The method is such that a key can be specifically prohibited from re-import at its originating device, or conversely, it can be specifically enabled for re-import at its originating device. The method of export/import control thwarts a form of insider attack wherein an accomplice at a receiving device uses one or more of the available cryptographic instructions to redirect a key back to the sending device (in a form suitable for recovery at the sending device).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 34% of the total text.

Enhanced Export Control of Cryptographic Keys via a Control Vector

       This article describes a method of enhanced export/import
control of cryptographic keys via a control vector-based key
management.  The method is such that a key generated at a sending
device for export to a receiving device is prevented from being
re-imported at the generating device.  The method is such that a key
can be specifically prohibited from re-import at its originating
device, or conversely, it can be specifically enabled for re-import
at its originating device. The method of export/import control
thwarts a form of insider attack wherein an accomplice at a receiving
device uses one or more of the available cryptographic instructions
to redirect a key back to the sending device (in a form suitable for
recovery at the sending device). Ordinarily, key management software
controls are a sufficient countermeasure against key manipulation
attacks of the type described.  However, for high security
applications, hardware countermeasures may be warranted.

      Existing forms of key management generate keys at a sending
device for export to receiving cryptographic devices in a form
suitable for recovery and use at the receiving cryptographic devices.
Most key management systems make use of a unidirectional key
distribution channel, which prohibits an intercepted encrypted key
from being recovered at the sending device.  In effect, an exported
key is in a form allowing recovery only at the intended receiving
device.  Two key management cryptographic instructions called
Reencipher From Master Key (RFMK) and Reencipher To Master Key
(RTMK), which make use of unidirectional key-encrypting keys, are
described in (*).  Using these instructions, it is not possible to
invert the key distribution process and recover a key at the same
device that originally generated the key.  In other words, RFMK and
RTMK are not inverse functions.  But two insider attackers, who could
subvert software key management controls, might overcome the intended
unidirectional key flow by redirecting received keys back to their
originating devices.  The key management method of this article
defends against such an attack.

      Two options for defending against the outlined attack are
described.  For purposes of explanation, the two options are shown
together in a single implementation.  The reader will appreciate that
only one of the two methods would most likely be implemented within a
cryptographic device.  Both methods make use of a special field
within the control vector C associated with the key-encrypting key KK
shared between the originating and receiving devices.  It is assumed
that each cryptographic device has a unique node identifier (node ID)
stored within the cryptographic hardware.

      With the first method, the control vector has a field called
EX_CV_ORIGIN, in which is stored a node identifier. At the time a key
is generated, the generating device v...