Remote key loading
Remote key loading is the process of installing symmetric encryption keys into a remotely located device from a central administrative site.
- Distribution of initial key encrypting keys (KEKs) to a newly installed device. A KEK is a type of symmetric encryption key that is used to encrypt other keys so that they can be securely transmitted over unprotected paths.
- Distribution of operational keys or replacement KEKs, enciphered under a KEK currently installed in the device.
| Verb name | Entry point | Offset | Access Control Point name and comments |
|---|---|---|---|
| Trusted Block Create | CSNDTBC | X'030F' | Trusted Block Create - Create Block in inactive form |
| Trusted Block Create | CSNDTBC | X'0310' | Trusted Block Create - Activate an inactive block |
| PKA Key Import | CSNDPKI | X'0311' | PKA Key Import - Import an external trusted block Convert a trusted block from external to internal format |
| PKA Key Import | CSNDPKI | X'0104' | PKA Key Import |
| Remote Key Export | CSNDRKX | X'0312' | Remote Key Export - Gen or export a non-CCA node key |
|
Key Generate |
CSNBKGN |
X'00DB' | Key Generate - SINGLE-R Replication of a single-length source key (which is either an RKX token or a CCA token) if the output symmetric encryption result is to be a CCA token, and the CV in the trusted block's Common Export Key Parameters TLV Object is 16 bytes with key form bits 'fff' set to X'010' for the left half and X'001' for the right half. |
| Key Import | CSNBKIM | X'027B' | Key Import - Unrestricted The importer key identifier in the initial code release must have unique halves. |
| Key Export | CSNBKEX | X'0276' | Key Export - Unrestricted The transport key identifier in the initial code release must have unique halves. |
Remote key loading methods
New remote key loading methods have been developed to overcome some of the shortcomings of the old manual key loading methods.
These new methods define acceptable techniques using public key cryptography to load keys remotely. Using these new methods, initial KEKs can be loaded without sending people to the remote device. This will reduce labor costs, be more reliable, and be much less expensive to install and change keys.
The new cryptographic features provide new methods for the creation and use of the special key forms needed for remote key distribution of this type. In addition, the new cryptographic features provide ways to solve long-standing barriers to secure key exchange with non-IBM cryptographic systems.
After an ATM is in operation, new keys can be installed as needed, by sending them enciphered under a KEK installed previously. This is straightforward in concept, but the cryptographic architecture in ATMs is often different from that of the host system that is sending the keys, and it is difficult to export the keys in a form understood by the ATM. For example, cryptographic architectures often enforce key-usage restrictions in which a key is bound to data describing limitations on how it can be used (for encrypting data, for encrypting keys, for operating on Message Authentication Codes (MACs), and so forth). The encoding of these restrictions and the method used to bind them to the key itself differs among cryptographic architectures, and it is often necessary to translate the format to that understood by the target device prior to a key being transmitted. It is difficult to do this without reducing security in the system; typically it is done by making it possible to arbitrarily change key-usage restrictions.
The methods described here provide a mechanism through which the system owner can securely control these translations, preventing the majority of attacks that could be mounted by modifying usage restrictions.
A data structure called a trusted block is defined to facilitate the remote key loading methods. The trusted block is the primary vehicle supporting these new methods. See Trusted blocks.