Security World Administrator Keys

A security world administrator key:

  • is an application key

  • has one of several possible types, dependent on its role and the security world’s ciphersuite

  • is blobbed under a logical token and stored in the world file

With the exception of KFIPS all these keys are blobbed under logical tokens found only on the administrator cardset, so this cardset must be exposed to use them. For the asymmetric keys their public halves are available from the world file.

KNSO (nCipher Security Officer’s Key)

This is an asymmetric integrity key blobbed under LTNSO.

It used for:

  • Signing world-binding certificates

  • Signing delegation certificates

  • Authorization trump operations groups in ACLs of other keys.

Its ACL has four groups:

  • A main use group allowing UseAsCertificate (for authorizing other operations) and MakeBlob. This has a time limit, configurable at world creation time (for example, using new-world --nso-timeout=…​)

  • A certificate signing group. This allows "just enough" Sign operations for world creation, and nothing more.

  • A certificate use group. This allows "just enough" UseAsCertificate operations for world creation, and nothing more. These operations are consumed during the blobbing of the other administrator keys, via their trump operations groups (which require KNSO authorization).

  • A single-use group allowing KNSO itself to be blobbed.

The certificate use group and the single-use group are restricted by use limits, rather than logical token hashes, because the logical token hashes are not available at this point in world creation.

It is variously known as:

  • The security officer’s key

  • The security world root key

  • The administrator key

  • The master key (in very old documentation)

  • The nCipher Security Officer’s key

In an NFKM_WorldInfo structure, hknso is the hash of KNSO and nsotimeout the time limit on the main use group.

KM (Security World Module Key)

This is a symmetric security key blobbed under LTM. During world initialization it is installed as a module key; in this role it has the following uses:

  • Protection of LTR, LTP, LTNV, LTRTC, LTDSEE, LTFTO and LTFIPS on administrator cardsets.

  • Protection of LTU and LTFIPS on operator cardsets.

  • Blobbing of module-protected application keys.

It is sometimes referred to as KMSW (the security world module key).

Its ACL has two groups:

  • A main use group, allowing its use as a module key.

  • A trump operations group.

    Note that trump operations group are present for administrator keys even in non-recoverable worlds. See Secret Key ACLs for further discussion of trump operations groups.

In an NFKM_WorldInfo structure, hkm is the hash of KM.

KMC (Module Certification Key)

This is an asymmetric integrity key blobbed under LTM. It is used to sign world-binding certificates.

Its ACL has two groups:

  • A main use group allowing Sign.

  • A trump operations group.

In an NFKM_WorldInfo structure, hkmc is the hash of KMC and blobpubkmc the public key blob.

KRE (Recovery Encryption Key)

This is an asymmetric security key, only present in recoverable worlds. It is blobbed under LTR. It used to encrypt and decrypt recovery blobs for application keys.

Its ACL has two groups:

  • A main use group allowing UseAsBlobKey.

  • A trump operations group.

In an NFKM_WorldInfo structure, hkre is the hash of KRE and blobpubkre the public key blob.

KRA (Recovery Authorization Key)

This is an asymmetric integrity key, only present in recoverable worlds. It is blobbed under LTR. It is not used in the current implementation.

The intention is to use it to supply authorization for recovery operations, a function currently performed by KNSO. There is no current plan to bring it into use.

Its ACL has two groups:

  • A main use group allowing UseAsCertificate.

  • A trump operations group.

In an NFKM_WorldInfo structure, hkra is the hash of KRA.

KP (Passphrase Recovery Key)

This is an asymmetric security key, only present in worlds supporting PIN (passphrase) recovery. It is blobbed under LTP. It is used to encrypt and decrypt operator card and softcard passphrases.

In a few places this key is referred to as KRP rather than KP. This may be considered an error.

Its ACL has two groups:

  • A main use group allowing Decrypt.

  • A trump operations group.

In an NFKM_WorldInfo structure, hkp is the hash of KP and blobpubkp the public key blob.

KFIPS (FIPS Authorization Key)

This is an asymmetric integrity key, only present in strict-FIPS world. It is blobbed under LTFIPS, which can be assembled from other administrator cards and operator cards. Its primary purpose is to authorize restricted operations in strict-FIPS worlds via delegation from KNSO, though it is also used to sign world-binding certificates.

Its ACL has two groups:

  • A main use group allowing UseAsCertificate and Sign, plus MakeBlob under any 1/64 logical token with KM.

  • A trump operations group.

In an NFKM_WorldInfo structure, hkfips is the hash of KFIPS and blobpubkfips the public key blob.

Delegation Keys

The delegation keys are:

  • KNV, blobbed under LTNV and authorizing NVRAM operations

  • KRTC, blobbed under LTRTC and authorizing RTC setting

  • KDSEE, blobbed under LTDSEE and authorizing SEE debugging

  • KFTO, blobbed under LTFTO and authorizing foreign token open

They are all asymmetric integrity keys and authorize their respective operations via delegation from KNSO. They are only present for worlds supporting the relevant operations.

Their ACLs have two groups:

  • A main use group allowing Sign and UseAsCertificate.

  • A trump operations group.

In an NFKM_WorldInfo structure, hknv, hkrtc, hkdsee and hkfto are the hashes of the delegation keys, if present. blobpubknv, blobpubkrtc, blobpubdsee and blobpubkfto are the public key blobs.

Key Types

The key types and mechanisms used in each role are as follows:

DLf1024s160mDES3

Symmetric integrity

DES3

Symmetric security

DES3

Working blob

DES3wSHA1

Temporary blob

DES3wSHA1

Asymmetric integrity

1024-bit DSA

Signature

DSA

Asymmetric security

1024-bit RSA

Recovery blob

RSApPKCS1
DLf1024s160mRijndael

Symmetric integrity

256-bit AES

Symmetric security

256-bit AES

Working blob

BlobCryptv2kHasheRijndaelCBC0hSHA1mSHA1HMAC

Temporary blob

BlobCryptv2kHasheRijndaelCBC0hSHA512mSHA512HMAC

Asymmetric integrity

1024-bit DSA

Signature

DSA

Asymmetric security

1024-bit RSA

Recovery blob

BlobCryptv2kRSAeRijndaelCBC0hSHA512mSHA512HMAC
DLf3072s256mRijndael

Symmetric integrity

256-bit AES

Symmetric security

256-bit AES

Working blob

BlobCryptv2kHasheRijndaelCBC0hSHA1mSHA1HMAC

Asymmetric integrity

3072-bit DSA

Signature

DSAhSHA256

Asymmetric security

3072-bit RSA

Recovery blob

BlobCryptv2kRSAeRijndaelCBC0hSHA512mSHA512HMAC
DLf3072s256mAEScSP800131Ar1

Symmetric integrity

256-bit AES

Symmetric security

256-bit AES

Working blob

BlobCryptv3kNoneeAESCBC0dCTRCMACmSHA256HMAC

Temporary blob

BlobCryptv3kNoneeAESCBC0dCTRCMACmSHA512HMAC

Asymmetric integrity

3072-bit DSA

Signature

DSAhSHA256

Asymmetric security

3072-bit RSA

Recovery blob

BlobCryptv3kRSAOAEPeAESCBC0dCTRCMACmSHA512HMAC
ECp521mAES

Symmetric integrity

256-bit AES

Symmetric security

256-bit AES

Working blob

BlobCryptv3kNoneeAESCBC0dCTRCMACmSHA256HMAC

Temporary blob

BlobCryptv3kNoneeAESCBC0dCTRCMACmSHA512HMAC

Asymmetric integrity

ECDSA P-521

Signature

ECDSAhSHA512

Asymmetric security

ECDH P-521

Recovery blob

BlobCryptv4kECDHeAESmCTRhSHA256mSHA256HMAC

Administrator Key API Calls

The C API is declared in nfkm.h:

  • KFIPS support is provided by NFKM_fips140auth(), NFKM_freefips140auth() and NFKM_newkey_makeauth(). Other NFKM_…​ functions take a FIPS handle where necessary. In general applications would be expected to use this API rather than supplying KFIPS and the delegation certificate manually, though there is no reason they can’t.

  • The NFKM_initworld_…​ functions are responsible for creating these keys and blobbing them under their respective logical tokens, and NFKM_loadworld_…​ for installing an existing KM when indoctrinating a module into an existing security world.

  • NFKM_replaceocs_…​ loads KRE so it can load recovery blobs and KNSO so it can make new key blobs.

  • NFKM_replaceacs_…​ loads keys for subsequent reblobbing under a new set of logical tokens.

  • NFKM_recoverpin_…​ loads KP so it can decrypt PIN recovery blobs.

  • NFKM_loadadminkeys_…​ loads arbitrary administrator keys.

  • NFKM_softcard_recoverpp() expects to be supplied a handle to KP so it can decrypt PIN recovery blobs.

In addition these operations are available as card-loading library logics, which is how most command line tools and the Connect’s front panel UI access them.

In Python:

  • nfkm.getfipsauth() and nfkm.makefipscert() provide KFIPS support.

  • There is no direct analogue to NFKM_initworld_…​ et al.

  • Card-loading library logics are available via the rqcard module.

Examples

nfkminfo can be used to reveal which administrator keys are present in a security world and what their hashes are:

$ nfkminfo
World
generation 2
state 0x1fa70000 Initialised Usable Recovery PINRecovery !ExistingClient RTC NVRAM FTO !AlwaysUseStrongPrimes SEEDebugForAll
n_modules 1
hknso 787720a1e305a5af6c8564af3f6bfe55122a733d
hkm 8fd82ce32e58f8e4b559dddb62de8cf65e66ce58 (type Rijndael)
hkmwk 1d572201be533ebc89f30fdd8f3fac6ca3395bf0
hkre a7ae9935f04f4680c3046a02c7fa838dd3ffd3ed
hkra 9d1e3c81989fb4db3df7a35df8d021721ff24064
hkmc 1527edda4cd26c7a8354e070bc026ec1ca01d68a
hkp 96ee8fc6732eb43c069dd555490dc2ff6a5b8e7c
hkrtc 1682e9ae78914ba594ae00da4115af51a596157b
hknv edde09e010bf98cca529416e8209565309ca7a59
hkdsee 24b4c4195f80b7d692877effe7bbd8423d3b11e9
hkfto dd30b3831985ebec7469f357e923d56aef514d7d
hkmnull 0100000000000000000000000000000000000000
ex.client none
...

To extra the current module configuration instead, use Cmd_GetKMList; see Module key API calls for an example.

From Python it is possible to retrieve the key hashes of individual administrator keys:

>>> nfkm.getinfo(conn)["hkre"]
"""a7ae9935 f04f4680 c3046a02 c7fa838d d3ffd3ed"""