3.14. Key Id Range and Purpose

These key ranges are used as a convention by the Middleware. Functionally (from applet point of view) they are the same. Only the “Applet reserved” keys have a special functionality as defined in the APDU specification of the secure element.

Purpose

Range

Customer keys

Start

0x00000001

End

0x7BFFFFFF

AKM Dynamic

Start

0x7C000000

End

0x7CFFFFFF

Middleware Use Cases and Demos

Start

0x7D000000

End

0x7DFFFFFF

Applet Reserved

Start

0x7FFF0000

End

0x7FFFFFFF

Managed by EdgeLock 2GO for different cloud onboarding

Start

0x80000000

End

0xEEFFFFFF

Middleware testing

Start

0xEF000000

End

0xEFFFFFFF

Required for EdgeLock 2GO

Start

0xF0000000

End

0xFFFFFFFF

3.15. Authentication Keys

Authentication object type

KeyID

UserID

0x7DA00001

UserID

0x7DA00011

AESKey

0x7DA00002

AESKey

0x7DA00012

ECKey

0x7DA00003

ECKey

0x7DA00013

Note

These authentication objects are used by the examples listed in Section 5Demo and Examples and are used as default authentication objects by the Middleware examples in case an applet session authentication is configured in the build options (See cmake-option-SE05X_Auth cmake-option-SE05X_Auth)

3.16. ECDAA Keys For Random Number

A random number(r) is reuqired when doing ECDAA sign. EC private key(key-r) is used to hold r. To reduce NVM operation, MW will not generate new key-r for each ECDAA sign. On the contrary, it will generate a specific key for each session. All the ECDAA sign operations in the same session will share the same key-r. Key ID 0x7DB0,0000 - 0x7DB0,FFFF is reserved for key-r. These keys are used internally by MW and can’t be generated or set by SSS API.

The mapping between session and key-r is calculated as following:

  • Default session will use Key-r ID 0x7DB00000

  • Applet session: Key-r ID = 0x7DB00001 + (Session Authentication ID) % 65535

Session Authentication ID

Random Key ID

Default session(session less)

0x7DB00000

0x00000001

0x7DB00001

0x00000002

0x7DB00002

0x0000FFFE

0x7DB0FFFE

0x0000FFFF

0x7DB0FFFF

0x00010000

0x7DB00001

0x00010001

0x7DB00002

Note

The reserved Key-r ID should be enough for most use cases. But in some corner case, 2 session may mapped to same Key-r(e.g., session auth ID 0x00000001 and 0x00010000 both are mapped to key 0x7DB00001). If that is the case, user can define their own mapping by changing sss_se05x_get_ecdaa_random_key_id().

3.17. Trust provisioned KeyIDs

The secure element gets as well trust provisioned with further keys and certificates which are ready to be used. The below table lists the usually used ones. Not all keys and certificates are available on all types, for a complete definition refer to “AN12436 SE050 Configurations” respectively “AN12973 SE051 configurations (1.0)”

Trust Provisioned object type

KeyID

ECC-256

Device Key

0xF0000100

Device Certificate

0xF0000101

Gateway Key

0xF0000102

Gateway Certificate

0xF0000103

RSA-2K

Device Key

0xF0000110

Device Certificate

0xF0000111

Gateway Key

0xF0000112

Gateway Certificate

0xF0000113

RSA-4K

Device Key

0xF0000120

Device Certificate

0xF0000121

Gateway Key

0xF0000122

Gateway Certificate

0xF0000123