C.3 Elliptic Curve Integrated Encryption Scheme (ECIES)

33.5013GPPRelease 18Security architecture and procedures for 5G SystemTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

C.3.1 General

The use of ECIES for concealment of the SUPI shall adhere to the SECG specifications [29] and [30]. Processing on UE side and home network side are described in high level in clauses C.3.2 and C.3.3.

When the SUPI is of type IMSI, the subscription identifier part of the IMSI (i.e., MSIN) that is used to construct the scheme-input shall be coded as hexadecimal digits using packed BCD coding where the order of digits within an octet is same as the order of MSIN digits specified in Figure 9.11.3.4.3a of TS 24.501 [35]. If the MSIN is composed of an odd number of digits, then the bits 5 to 8 of final octet shall be coded as "1111".

When the SUPI is of type network specific identifier, the subscription identifier part of the SUPI that is used to construct the scheme-input shall follow the encoding rules specified in Annex B.2.1.2 of TS 33.220 [28].

C.3.2 Processing on UE side

The ECIES scheme shall be implemented such that for computing a fresh SUCI, the UE shall use the provisioned public key of the home network and freshly generated ECC (elliptic curve cryptography) ephemeral public/private key pair according to the ECIES parameters provisioned by home network. The processing on UE side shall be done according to the encryption operation defined in [29]. with the following changes to Section 3.8 and step 5 and 6 of Section 5.1.3.

– generate keying data K of length enckeylen + icblen + mackeylen.

– Parse the leftmost enckeylen octets of K as an encryption key EK, the middle icblen octets of K as an ICB, and
the rightmost mackeylen octets of K as a MAC key MK.

The final output shall be the concatenation of the ECC ephemeral public key, the ciphertext value, the MAC tag value, and any other parameters, if applicable.

NOTE: The reason for mentioning "any other parameter, if applicable" in the final output is to allow cases, e.g. to enable the sender to send additional sign indication when point compression is used.

The Figure C.3.2-1 illustrates the UE’s steps.

Figure C.3.2-1: Encryption based on ECIES at UE

C.3.3 Processing on home network side

The ECIES scheme shall be implemented such that for deconcealing a SUCI, the home network shall use the received ECC ephemeral public key of the UE and the private key of the home network. The processing on home network side shall be done according to the decryption operation defined in [29]. with the following changes to Section 3.8 and step 6 and 7 of Section 5.1.4.

– generate keying data K of length enckeylen + icblen + mackeylen.

– Parse the leftmost enckeylen octets of K as an encryption key EK, the middle icblen octets of K as an ICB, and
the rightmost mackeylen octets of K as a MAC key MK.

NOTE: Unlike the UE, the home network does not need to perform a fresh ephemeral key pair generation for each decryption. How often the home network generates new public/private key pair and how the public key is provisioned to the UE are out of the scope of this clause.

The Figure C.3.3-1 illustrates the home network’s steps.

Figure C.3.3-1: Decryption based on ECIES at home network

C.3.4 ECIES profiles

C.3.4.0 General

Unless otherwise stated, the ECIES profiles follow the terminology and processing specified in SECG version 2 [29] and [30]. The profiles shall use "named curves" over prime fields.

For generating successive counter blocks from the initial counter block (ICB) in CTR mode, the profiles shall use the standard incrementing function in section B.1 of NIST Special Publication 800-38A [16] with m = 32 bits. The ICB corresponds to T₁ in section 6.5 of [16].

The value of the MAC tag in ECIES, shall be the L most significant octets of the output generated by the HMAC function, where L equals to the maclen.

Profile A shall use its own standardized processing for key generation (section 6 of RFC 7748 [46]) and shared secret calculation (section 5 of RFC 7748 [46]). The Diffie-Hellman primitive X25519 (section 5 of RFC 7748 [46]) takes two random octet strings as input, decodes them as scalar and coordinate, performs multiplication, and encodes the result as an octet string. The shared secret output octet string from X25519 shall be used as the input Z in the ECIES KDF (section 3.6.1 of [29]). As the point compression is not applied for profile A, the prefix rule for compression type defined in [29] section 5.1.3 shall not be used in profile A, i.e., there shall be no prefix for the ephemeral public key of Profile A.

Profile B shall use point compression to save overhead and shall use the Elliptic Curve Cofactor Diffie-Hellman Primitive (section 3.3.2 of [29]) to enable future addition of profiles with cofactor h ≠ 1. For curves with cofactor h = 1 the two primitives (section 3.3.1 and 3.3.2 of [29]) are equal.

The profiles shall not use backwards compatibility mode (therefore are not compatible with version 1 of SECG).

C.3.4.1 Profile A

The ME and SIDF shall implement this profile. The ECIES parameters for this profile shall be the following:

– EC domain parameters : Curve25519 [46]

– EC Diffie-Hellman primitive : X25519 [46]

– point compression : N/A

– KDF : ANSI-X9.63-KDF [29]

– Hash : SHA-256

– SharedInfo₁ : (the ephemeral public key octet string – see [29] section 5.1.3)

– MAC : HMAC–SHA-256

– mackeylen : 32 octets (256 bits)

– maclen : 8 octets (64 bits)

– SharedInfo₂ : the empty string

– ENC : AES–128 in CTR mode

– enckeylen : 16 octets (128 bits)

– icblen : 16 octets (128 bits)

– backwards compatibility mode : false

C.3.4.2 Profile B

The ME and SIDF shall implement this profile. The ECIES parameters for this profile shall be the following:

– EC domain parameters : secp256r1 [30]

– EC Diffie-Hellman primitive : Elliptic Curve Cofactor Diffie-Hellman Primitive [29]

– point compression : true