ECIES for 5G
Prior to Luna HSM Firmware 7.7.2, for the Luna implementation of ECIES AES-CTR, it was required to supply the Initial Counter Block (ICB) or else all zeroes for that parameter. Luna HSM Firmware 7.7.2 onward adds the derivation (Key Derivation Function) of the ICB to the encryption scheme. This supports 5G 3GPP TS 33.501 standard by enabling the Luna HSM to process 5G 3GPP SUCI (SUbscription Concealed Identifier) de-concealement requests.
Profiles Supported
The ECIES decryption operation maps to the “home network side” (HN), while encryption maps to User Equipment (UE) such as phones and other devices. Two profiles each with specific ECIES parameters are supported:
>Profile A:
•ECC: Curve25519
>Profile B:
•ECC: secp256r1 (same as prime256v1)
Both require Shared Data for KDF: compressed ephemeral public key.
Test vectors, included in the 33.501 standard, can be used to verify firmware compliance.
Decryption
In firmware older than Luna HSM Firmware 7.7.2, the ECIES mechanism parameter structure CK_ECIES_PARAMS uses a 0-byte ICB or IV for all encryption schemes.
>For AES-CTR this results in an ICB of 16 0x0 bytes and counterBits = 0x0.
In Luna HSM Firmware 7.7.2 and onward, CK_ECIES_PARAMS interpretation has been changed for AES-CTR in firmware:
>Firmware now derives an extra 16 bytes for the ICB in the KDF step and uses a 32-bit counter for decryption.
>To derive the ICB using CK_ECIES_PARAMS_EXT, set the encryption scheme mechanism parameters to no parameters (NULL, 0 length).
The ephemeral public key can now be in compressed format.
•It is uncompressed for the Key Agreement step (Curve25519 is already compressed).
The 3GPP TS 33.501 standard requires the compressed ephemeral public key to be passed into the KDF via “sharedData1” mechanism parameter.
The ECIES encryption mechanism was changed for AES-CTR to derive an ICB.
The ephermal public key is generated each time so it cannot be sent into the KDF derivation through “sharedData1”.
To test ECIES encryption with the new ECIES decryption a new CK_ECIES_PARAMS_EXT2 structure ( Luna HSM Client 10.4 onward) takes parameter kdfSharedDataFlags added:
>0 = no addition to shared data (sharedData1)
>1 = shared data | ephemeral public key
>2 = shared data | compressed ephemeral public key
>3 = ephemeral public key | shared data
>4 = compressed ephemeral public key | shared data
This allows the encryption or decryption to add the ephemeral public key to the KDF without using the “sharedData1” parameter.
Luna 5G OP flags and message response TLV tag definitions
#define LUNA_5G_OPC 0x00000001 // OPC is provided rather than OP
#define LUNA_5G_ENCRYPTED_OP 0x00000002 // OP or OPC is passed in encrytped by Storage Key
#define LUNA_5G_OP_OBJECT 0x00000004 // OP or OPC is an object in HSM partition
#define LUNA_5G_USE_TLV 0x00000008 // Use the Tag/Length/Value format in return string
#define LUNA_5G_USER_DEFINED_RC 0x00000010 // User has defined his own R and C constants for Milenage
#define LUNA_5G_TAG_RANDOM 0x00000001 // Random data generated in HSM
#define LUNA_5G_TAG_RES 0x00000002 // Response string
#define LUNA_5G_TAG_CK 0x00000003 // Confidentiality Key
#define LUNA_5G_TAG_IK 0x00000004 // Integrity Key
#define LUNA_5G_TAG_SQN_XOR_AK 0x00000005 // Sequence # xor'd with Anonymity Key (AK)
#define LUNA_5G_TAG_AMF 0x00000006 // Authentication Management Field
#define LUNA_5G_TAG_MAC 0x00000007 // MAC-A for authentication
#define LUNA_5G_TAG_SEQUENCE 0x00000008 // Sequence number for response to resynch operation
typedef struct CK_MILENAGE_SIGN_PARAMS {CK_ULONG ulMilenageFlags;
CK_ULONG ulEncKiLen;
CK_BYTE_PTR pEncKi;
CK_ULONG ulEncOPcLen;
CK_BYTE_PTR pEncOPc;
CK_OBJECT_HANDLE hSecondaryKey;
CK_OBJECT_HANDLE hRCKey;
CK_BYTE sqn[6];
CK_BYTE amf[2];
} CK_MILENAGE_SIGN_PARAMS;
typedef CK_MILENAGE_SIGN_PARAMS CK_PTR CK_MILENAGE_SIGN_PARAMS_PTR;
typedef struct CK_TUAK_SIGN_PARAMS {CK_ULONG ulTuakFlags;
CK_ULONG ulEncKiLen;
CK_BYTE_PTR pEncKi;
CK_ULONG ulEncTOPcLen;
CK_BYTE_PTR pEncTOPc;
CK_ULONG ulIterations;
CK_OBJECT_HANDLE hSecondaryKey;
CK_ULONG ulResLen;
CK_ULONG ulMacALen;
CK_ULONG ulCkLen;
CK_ULONG ulIkLen;
CK_BYTE sqn[6];
CK_BYTE amf[2];
} CK_TUAK_SIGN_PARAMS;
typedef CK_TUAK_SIGN_PARAMS CK_PTR CK_TUAK_SIGN_PARAMS_PTR;
typedef struct CK_COMP128_SIGN_PARAMS {CK_ULONG ulVersion;
CK_ULONG ulEncKiLen;
CK_BYTE_PTR pEncKi;
} CK_COMP128_SIGN_PARAMS;
typedef CK_COMP128_SIGN_PARAMS CK_PTR CK_COMP128_SIGN_PARAMS_PTR;
typedef struct CK_KEY_TRANSLATE_PARAMS {CK_FLAGS ulFlags;
CK_MECHANISM mWrapMech;
CK_MECHANISM mUnWrapMech;
CK_BYTE_PTR pData;
CK_ULONG ulDataLen;
CK_OBJECT_HANDLE hUnwrapKey;
} CK_KEY_TRANSLATE_PARAMS;
typedef CK_KEY_TRANSLATE_PARAMS CK_PTR CK_KEY_TRANSLATE_PARAMS_PTR;
Summary
The decision comes down to using the CKM_ECIES mechanism while passing
>either CK_ECIES_PARAMS
> or CK_ECIES_PARAMS_EXT
parameter structures filled out to select the AES-CTR encryption scheme.
For CK_ECIES_PARAMS_EXT specify no extra encryption scheme parameters:
pEncSchemeMechanismParameter = NULL
ulEncSchemeMechanismParameterLen = 0
This causes the AES-CTR ICB to be derived.
Tools
For Luna HSM Client 10.4 onward:
>CKDEMO was changed to allow zero-length AES-CTR bits and to support KDF flags selection.
>MULTITOKEN and FMULTITOKEN changed to allow selecting AES-CTR or AES_CBC_PAD for all the “eciesaes…” modes.
