페이지 선택
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in pages

Chapter 3. Cryptographic Primitives

 

This chapter introduces the various cryptographic primitives, algorithms and protocol building blocks used in this protocol. It introduces for each of them a functional abstraction that can be referred to in the other chapters of this specification. This chapter also maps those cryptographic primitives to specific instances with the corresponding appropriate informative or normative refer­ ences. Wherever relevant, it also gives necessary or relevant information about the use of these mappings in a specific context to achieve a compliant implementation.

Given a version of the Message Format, the cryptographic primitives are mapped to specific instances. There is no cryptosuite negotiation in this protocol: one version of the Message Format has one cryptosuite as defined in this chapter.

Each section defines cryptographic primitives generically, together with concrete mappings to spe­ cific instances of these cryptographic primitives for version 1.0 of the Message Format. This chapter can also be used as guidance about which cryptographic primitives need to be supported by a device, but it must be noted that not all devices will have to support all of them. For example, a

device may not  require the  Crypto_PBKDF() primitive, as values  based on  this  operation could  in

some instances be precomputed and stored during the manufacturing process of the device. The

proposed functional mapping in this chapter is normative with respect to the values computed by the functions but informative with respect to the way the functions are interfaced within imple­

mentations. For example, a function returning both a boolean to indicate success and a value if the

operation is successful could also be implemented using exception mechanisms instead of return­ ing a boolean.

 

It must also be noted that not all cryptographic primitives are exposed to the other parts of the specification. For example, the Crypto_TRNG() primitive SHALL NOT be called outside of the Crypto_­ DRBG() implementation.

The cryptographic primitives discussed below operate on data local to the host. Where more com­ plex data types are present and their external representation is applicable, the chapter notes the details of the encoding. Simple multi-byte data types without any additional context are assumed to be in host byte order when they are used internally to a procedure, unless otherwise stated.

All octet strings are presented with first octet having index 0, and presented from left to right for indices 0 through N-1 for an octet string of length N.

 

 

 

3.1.   Deterministic Random Bit Generator (DRBG)

 

This protocol relies on random numbers for many security purposes. For example, random num­ bers  are  used  in  generating  secret  keys,  counters,  cryptographic  signature  generation random

secrets, etc. Those random numbers SHALL be generated using the Crypto_DRBG() function.

 

 

 

Mapping (Version 1.0)

Crypto_DRBG() SHALL be implemented with one of the following DRBG algorithms as defined in NIST 800-90A (the choice of which one is left to the manufacturer because the choice has no

impact on the interoperability):

 

•   CTR DRBG (with AES-CTR)

•   HMAC DRBG (with SHA-256)

•   HMAC DRBG (with SHA-512)

•   Hash DRBG (with SHA-256)

•   Hash DRBG (with SHA-512)

Crypto_DRBG() SHALL be seeded using Crypto_TRNG() with at least 256 bits of entropy (see among others Chapter 4 and Section 8.4 of NIST 800-90A).

 

 

 

3.2.   True Random Number Generator (TRNG)

 

A TRNG (aka. Entropy Source) is required to provide an entropy seed as an input to the DRBG algo­ rithm.

 
   

 

Mapping (Version 1.0)
Crypto_TRNG() MAY be implemented according to the NIST 800-90B implementation guidelines but alternate implementations MAY be used.

 

In accordance with good security practices, the Crypto_TRNG() SHALL never be called directly but rather SHALL be used in the implementation of Crypto_DRBG().

 

 

3.3.   Hash function (Hash)

 

Crypto_Hash() computes the cryptographic hash of a message.

 

 

 

Mapping (Version 1.0)
int CRYPTO_HASH_LEN_BITS := 256
int CRYPTO_HASH_LEN_BYTES := 32
int CRYPTO_HASH_BLOCK_LEN_BYTES := 64

Crypto_Hash(message) :=

byte[CRYPTO_HASH_LEN_BYTES] SHA-256(M := message)

 

SHA-256() SHALL be computed as defined in Section 6.2 of FIPS 180-4.

 

 

 

3.4.   Keyed-Hash Message Authentication Code (HMAC)

 

Crypto_HMAC() computes the cryptographic keyed-hash message authentication code of a message.

 
   

 

 

 

3.5.   Public Key Cryptography

 

Matter specifies the following scheme and parameters for public key cryptography.

 

3.5.1.  Group

 

The public key cryptography of Matter relies on the group defined in the following mapping table.

 

Mapping (Version 1.0)
Matter public key cryptography SHALL be based on Elliptic Curve Cryptography (ECC) with the elliptic curve: secp256r1 defined in Section 2.4.2 of SEC 2. (Informative: Note that this curve is also referred to as NIST P-256 or prime256v1 in FIPS 186-4 and NIST 800-186.)
PrivateKey is an opaque data type to hold either the private key or any handle or reference that allows other primitives to access the corresponding private key.

PublicKey is an opaque data type to hold the public key or any handle or reference that allows other primitives to access the corresponding public key. A public key is a point on the elliptic curve. (Note: at places in the specification where public keys are to be explicitly transmitted, the

format in which they are transmitted is specified.)

int CRYPTO_GROUP_SIZE_BITS := 256
int CRYPTO_GROUP_SIZE_BYTES := 32
int CRYPTO_PUBLIC_KEY_SIZE_BYTES : = (2 * CRYPTO_GROUP_SIZE_BYTES) + 1 = 65 is the size in bytes of the public key representation when encoded using the uncompressed public key format as spec­ ified in section 2.3 of SEC 1.

struct {

PublicKey publicKey; PrivateKey privateKey;

} KeyPair;

 

3.5.2. Key generation

 

Crypto_GenerateKeyPair() is the function to generate a key pair.

 
   

 

 

3.5.3.  Signature and verification

 

Crypto_Sign() is used to sign a message, and Crypto_Verify() is used to verify a signature on a mes­ sage.

These functions either generate or verify a signature of type Signature defined by the following mapping.

 
   

 

3.5.3.1.  Signature

 

 
   

 

 

  • Signature verification
 
   

 

 

 

  • ECDH

Crypto_ECDH() is used to compute a shared secret from the Elliptic Curve Diffie-Hellman (ECDH) pro­ tocol.

 
   

 

 

3.5.5.  Certificate validation

 

Crypto_VerifyChain() is used to verify Matter certificates.

Crypto_VerifyChainDER() is used to verify public key X.509 v3 certificates in X.509 v3 DER format.

 
   

 

 

Mapping (Version 1.0)

 

Crypto_VerifyChain(certificates) := boolean verified

 

verified is TRUE if the Matter certificates are verified as prescribed by RFC 5280.

 

Crypto_VerifyChainDER(certificates) := boolean verified

 

verified is TRUE if the certificates are verified as prescribed by RFC 5280.

 

The primitives as described above verify cryptographic integrity of the certificate chains. This spec­ ification imposes a number of additional constraints on certificates discussed below in sections on Device Attestation Certificates, Node Operational Certificates and Certificate Common Conventions.

 

3.5.6.  Time and date considerations for certificate path validation

 

The Basic Path Validation algorithm in RFC 5280 mandates the consideration of the “current time” against the validity period (notBefore, notAfter fields) when validating paths. The usage of “current time” assumes that such a time is available and correct, which is a strong assumption when consid­

ering some constrained devices or devices only locally reachable on a network in the absence of infrastructure to synchronize time against a global real-time reference.

When the Crypto_VerifyChain primitive is used, rather than overriding the Basic Path Validation algorithm of RFC 5280, Nodes SHALL consider the following definition of “current time” that accounts for the possible lack of a real time reference:

 

  • If a Node has a current real-time clock value which is trusted according to implementation- defined means to be accurate with regard to global real-time, whether using Time Synchroniza­ tion features of this specification or other means, then it SHALL use that time;
  • Otherwise, the current time SHALL be set to the last-known-good UTC

 

Upon failure to validate a certificate path, where the only reason for failure is an invalid validity period of a path element, a Node MAY apply a policy of its choice to determine whether to ignore

 

this failure and still consider the path valid.

 

3.5.6.1.  Last Known Good UTC Time

 

Nodes SHALL maintain a stored Last Known Good UTC Time. This time is used as a fallback for cryptographic credentials expiry enforcement, if all other available time synchronization mecha­ nisms fail.

The last known good UTC time SHALL be updated at commissioning and MAY be updated after a successful time synchronization, or by an embedded time in an OTA. Nodes SHOULD store a Last Known Good UTC Time value to persistent storage at least once a month. A Node’s initial out-of-box Last Known Good UTC time SHALL be the compile-time of the firmware.

A Node MAY adjust the Last Known Good UTC Time backwards if it believes the current Last Known Good UTC Time is incorrect and it has a good time value from a trusted source. The Node SHOULD NOT adjust the Last Known Good UTC to a time before the later of:

  • The build timestamp of its currently running software image
  • The not-before timestamp of any of its operational certificates (see Section 6.4.5, “Node Opera­ tional Credentials Certificates”).

If a Node has used the Last Known Good UTC Time, it SHOULD recheck its security materials and existing connections if it later achieves time synchronization.

 

 

 

3.6.   Data Confidentiality and Integrity

 

Symmetric block ciphers are used to provide message security.

 

All unicast and multicast messages between Nodes requiring protection for confidentiality and integrity with data origin authentication SHALL use Authenticated Encryption with Associated Data (AEAD) as primitive to protect those messages.

 

 

Mapping (Version 1.0)

Data confidentiality and integrity SHALL use the AES-CCM mode as defined in NIST 800-38C with the following parameters:

•   int CRYPTO_SYMMETRIC_KEY_LENGTH_BITS := 128 (this is the key length of the underlying block cipher in bits)

•   int CRYPTO_SYMMETRIC_KEY_LENGTH_BYTES := 16 (this is the key length of the underlying block cipher in bytes)

•   int CRYPTO_AEAD_MIC_LENGTH_BITS := 128 (this is the MIC length in bits)

•   int CRYPTO_AEAD_MIC_LENGTH_BYTES := 16 (this is the MIC length in bytes)

•   int CRYPTO_AEAD_NONCE_LENGTH_BYTES := 13

•   Key length SHALL be CRYPTO_SYMMETRIC_KEY_LENGTH_BITS bits.

•   MIC length SHALL be CRYPTO_AEAD_MIC_LENGTH_BITS bits.

•   The parameter q SHALL be 2 (length of encoding of maximum length) as specified in Appendix

A.1 of NIST 800-38C.

•   The parameter n SHALL be CRYPTO_AEAD_NONCE_LENGTH_BYTES (length of nonce in bytes) as speci­ fied in Appendix A.1 of NIST 800-38C.

SymmetricKey is an opaque data type to hold a symmetric block cipher key or any handle or refer­ ence that allows other primitives to access the corresponding key.

 

3.6.1.  Generate and encrypt

 

 
   

 

 

 

  • Decrypt and verify

 

Function and description

 
   

 

Performs the decrypt and verify computation on the combined ciphertext and tag C and the associ­ ated data A using the key K and a nonce N. Note that the encoding of C depends on the mapping of the specific instance of the cryptography primitive.

 

This function has two outcomes:

 

  • If tag verification succeeds, the success output is TRUE and the payload array contains the decrypted payload P.
  • If tag verification fails, the success output is FALSE and the contents of the payload array is undefined.

 

 

 

 

3.7.   Message privacy

 

Message privacy is implemented using a block cipher in CTR mode.

 

Mapping (Version 1.0)

Message privacy SHALL use the AES-CTR mode as defined in NIST 800-38A with the following parameters:

•   int CRYPTO_PRIVACY_NONCE_LENGTH_BYTES := 13

•   Key length SHALL be CRYPTO_SYMMETRIC_KEY_LENGTH_BITS bits.

 

3.7.1.  Privacy encryption

 

 
   

 

 

 

  • Privacy decryption
 
   

 

 

 

 

3.8.   Key Derivation Function (KDF)

 

Matter specifies the following key derivation function to generate encryption keys.

 

Function and description

bit[len] Crypto_KDF(

byte[] inputKey, byte[] salt, byte[] info,

int len)

Returns the key of len bits derived from inputKey using the salt and the info; len SHALL be a mul­ tiple of 8.

 

Mapping (Version 1.0)

Crypto_KDF(inputKey, salt, info, len) := bit[len] HKDF-Expand(

PRK := HKDF-Extract(salt := salt, IKM := inputKey), info := info, L := (len / 8))

HKDF-Extract SHALL be the HKDF-Extract primitive from RFC 5869 sec 2.2 using Crypto_HMAC (i.e. HMAC-SHA256) as the auxiliary HMAC-Hash function.

HKDF-Expand SHALL be the HKDF-Expand primitive from RFC 5869 sec 2.3 using Crypto_HMAC (i.e. HMAC-SHA256) as the auxiliary HMAC-Hash function.

The primitive returns a bit array of len bits.

 

When multiple keys of the same length are generated by a single KDF call, the following shorthand notation can be used:

 

Key1 || Key2 || Key3 = Crypto_KDF (

inputKey = inputKeyMaterial, salt = [],

info = [],

// 3 below matches number of keys expressed in concatenated output len = 3 * CRYPTO_SYMMETRIC_KEY_LENGTH_BITS

)

This is equivalent to the following:

 

Keys = Crypto_KDF (

inputKey = inputKeyMaterial, salt = [],

info = [],

len = 3 * CRYPTO_SYMMETRIC_KEY_LENGTH_BITS

 

)

 

  1. Set Key1 to the CRYPTO_SYMMETRIC_KEY_LENGTH_BITS most significant bits of Keys.
  2. Set Key2 to the next CRYPTO_SYMMETRIC_KEY_LENGTH_BITS significant bits of Keys.
  3. Set Key3 to the CRYPTO_SYMMETRIC_KEY_LENGTH_BITS least significant bits of Keys.

 

 

 

3.9.   Password-Based Key Derivation Function (PBKDF)

 

Matter specifies the following password-based key derivation function to compute a derived key from a cryptographically weak password.

 
   

 

 

Mapping (Version 1.0)
int CRYPTO_PBKDF_ITERATIONS_MIN := 1000
int CRYPTO_PBKDF_ITERATIONS_MAX := 100000

Crypto_PBKDF(input, salt, iterations, len) :=

bit[len] PBKDF2(P := input, S := salt, C := iterations, kLen := len)

 

PBKDF2() SHALL be the HMAC-based PBKDF function with Crypto_HMAC(key := P, message := U[j- 1]) as the auxiliary function HMAC as defined in Section 5.3 of NIST 800-132; it returns a bit array of len bits.

 

 

 

 

3.10.   Password-Authenticated Key Exchange (PAKE)

 

This protocol uses password-authenticated key exchange (PAKE) for the PASE protocol.

 

Mapping (Version 1.0)

Matter uses SPAKE2+ as described in SPAKE2+ as PAKE with:

 

•   The SPAKE2+ verifier is the Commissionee/Responder and the SPAKE2+ prover is the Commis­ sioner/Initiator

•   Crypto_PBKDF() as underlying PBKDF (see Section 3.9, “Password-Based Key Derivation Func­ tion (PBKDF)”), with arguments as described in the definition of Crypto_PAKEValues_Initiator

•   NIST P-256 elliptic curve as underlying group (see Section 3.5.1, “Group”).

◦        SPAKE2+ requires two additional points on the curve: M and N. The values of M and N are taken from the draft version 2 of the SPAKE2+ specification (SPAKE2+) and are listed below in compressed format (format defined in section 2.3 of SEC 1):

▪        M = 02886e2f97ace46e55ba9dd7242579f2993b64e16ef3dcab95afd497333d8fa12f

▪        N = 03d8bbd6c639c62937b04d997f38c3770719c629d7014d49a24b4f98baa1292b49

•   Crypto_Hash() as underlying hash function (see Section 3.3, “Hash function (Hash)”).

•   Crypto_HMAC() as underlying HMAC function (see Section 3.4, “Keyed-Hash Message Authentica­ tion Code (HMAC)”).

•   KDF(info, key, salt) := Crypto_KDF(key, salt, info, CRYPTO_HASH_LEN_BITS) as underlying KDF function (see Section 3.8, “Key Derivation Function (KDF)”).

 

Mapping (Version 1.0)

Crypto_PAKEValues_Initiator := (w0, w1) where w0 and w1 SHALL be computed as follows:

 

CRYPTO_W_SIZE_BYTES := CRYPTO_GROUP_SIZE_BYTES + 8 CRYPTO_W_SIZE_BITS := CRYPTO_W_SIZE_BYTES * 8

 

byte w0s[CRYPTO_W_SIZE_BYTES] || byte w1s[CRYPTO_W_SIZE_BYTES] = (byte[2 * CRYPTO_W_SIZE_BYTES])

bit[2 * CRYPTO_W_SIZE_BITS]

Crypto_PBKDF(passcode, salt, iterations, 2 * CRYPTO_W_SIZE_BITS) byte w0[CRYPTO_GROUP_SIZE_BYTES] = w0s mod p

byte w1[CRYPTO_GROUP_SIZE_BYTES] = w1s mod p

 

where:

•   mod is the mathematical modulo operation and || is the string concatenation or split operator.

•   passcode, is the Passcode defined in Section 5.1.1.6, “Passcode”, serialized as little-endian over 4 octets. For example, passcode 18924017 would be encoded as the octet string f1:c1:20:01 and the passcode 00000005 would be encoded as the octet string 05:00:00:00.

•   p is the order of the underlying elliptic curve.

•   Both w0s and w1s SHALL have a length equal to (CRYPTO_GROUP_SIZE_BYTES + 8).

•   salt and iterations are extracted from the Crypto_PBKDFParameterSet values.

•   The pair (w0,w1) is also referred to as Commissioner PAKE input

 

Mapping (Version 1.0)

Crypto_PAKEValues_Responder := (w0, L) where w0 and L SHALL be computed as follows:

 
   

 

where:

  • passcode, is the Passcode defined in Section 5.1.1.6, “Passcode”.
  • p is the order of the elliptic curve to be used.
  • Both w0s and w1s SHALL have a length equal to (CRYPTO_GROUP_SIZE_BYTES + 8).
  • salt and iterations are extracted from the Crypto_PBKDFParameterSet
  • P is the generator of the underlying elliptic curve.
  • When the computation of Crypto_PAKEValues_Responder is done, fields w0 and L SHALL be stored in the Responder and w1 SHALL NOT be stored in the Responder.
  • The pair (w0,L) is also referred to as Commissionee PAKE input or verification value

 

  • Computation of pA
 
   

 

  • Computation of pB
 
   

 

  • Computation of transcript TT

 

Mapping (Version 1.0)

 

Crypto_Transcript(PBKDFParamRequest, PBKDFParamResponse, pA, pB) := byte[] TT

 

Crypto_Transcript() SHALL compute TT as specified in SPAKE2+ with:

 

byte ContextPrefixValue [26] = {

0x43, 0x48, 0x49, 0x50, 0x20, 0x50, 0x41, 0x4b, 0x45, 0x20, 0x56, 0x31, 0x20, 0x43,

0x6f, 0x6d,

0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x69, 0x6e, 0x67

} // “CHIP PAKE V1 Commissioning” – The usage of CHIP here is intentional and due to implementation in the SDK before the name change, should not be renamed to Matter.

Context := Crypto_Hash(ContextPrefixValue || PBKDFParamRequest || PBKDFParamResponse) TT :=

lengthInBytes(Context)           || Context                             ||

0x0000000000000000             || 0x0000000000000000 ||

lengthInBytes(M)                     || M                                        ||

lengthInBytes(N)                      || N                                         ||

lengthInBytes(pA)                    || pA                                      ||

lengthInBytes(pB)                    || pB                                       ||

lengthInBytes(Z)                       || Z                                         ||

lengthInBytes(V)                       || V                                         || lengthInBytes(w0)                    || w0

 

Z and V SHALL be computed from pA and pB as specified in SPAKE2+.

Note the two 0x0000000000000000 null-lengths indicate that no identities are present and each null- lengths is 8 bytes wide since it is specified by the SPAKE2+ specification that lengths are eight-byte little-endian numbers. The SPAKE2+ specification indicates that we must include these length

fields.

Note in case PBKDFParamRequest and PBKDFParamResponse messages are not exchanged, they SHALL be replaced by empty strings in the Context computation.

 

  • Computation of cA, cB and Ke

 

Mapping (Version 1.0)

Crypto_P2(TT, pA, pB) :=

{byte cA[CRYPTO_HASH_LEN_BYTES], byte cB[CRYPTO_HASH_LEN_BYTES], byte Ke[CRYPTO_HASH_LEN_BYTES/2]}

 

Crypto_P2() SHALL compute cA, cB and Ke as specified in SPAKE2+ with cA := CRYPTO_HMAC(KcA,pB)

and cB := CRYPTO_HMAC(KcB,pA).

 

 

 

 

 

Adsense

 

 WiFi IoT Module

 

www.mxchip.com

 

 

 Bluetooth Module

www.feasycom.com

 

 

 5G/LTE/CAT-M1/NB-IoT

 

www.simcom.com

 

Viewed Page List