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.
|
|
|
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¶
|
|
UserID |
0x7DA00001 |
UserID |
0x7DA00011 |
AESKey |
0x7DA00002 |
AESKey |
0x7DA00012 |
ECKey |
0x7DA00003 |
ECKey |
0x7DA00013 |
Note
These authentication objects are used by the examples listed in Section 5 — Demo 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
|
|
|
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)”
|
|
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 |