OPTIGA device Data Object Boundary Exceeded - after storing ECC Private&Public key #22
-
Why is the data boundary exceeded ?
Slot 0xE0E0 contains Optiga Certificate New ECC key created and stored in 0xE0F1, public stored in slot 0x0xF1D1
But now executing 8806:Error [0x8008] : OPTIGA device Data Object Boundary Exceeded |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 3 replies
-
Hello @Kitty-Hawk1 here is a small description of this failure (0x08) - https://github.com/Infineon/optiga-trust-m/wiki/Device-Error-Codes |
Beta Was this translation helpful? Give feedback.
-
Hi, I was following the example on the web page https://github.com/Infineon/linux-optiga-trust-m
But
Master |
Beta Was this translation helpful? Give feedback.
-
Interesting. pi@yushevpi:~/git/linux-optiga-trust-m/bin $ ./trustm_data -r 0xe0e0 -o teste0e0.crt
========================================================
Device Public Key IFX [0xE0E0]
[Size 0514] :
C0 01 FF 00 01 FC 00 01 F9 30 82 01 F5 30 82 01
7C A0 03 02 01 02 02 04 7E A2 FE CC 30 0A 06 08
2A 86 48 CE 3D 04 03 03 30 72 31 0B 30 09 06 03
55 04 06 13 02 44 45 31 21 30 1F 06 03 55 04 0A
0C 18 49 6E 66 69 6E 65 6F 6E 20 54 65 63 68 6E
6F 6C 6F 67 69 65 73 20 41 47 31 13 30 11 06 03
55 04 0B 0C 0A 4F 50 54 49 47 41 28 54 4D 29 31
2B 30 29 06 03 55 04 03 0C 22 49 6E 66 69 6E 65
6F 6E 20 4F 50 54 49 47 41 28 54 4D 29 20 54 72
75 73 74 20 4D 20 43 41 20 33 30 30 30 1E 17 0D
32 30 30 39 31 30 31 31 34 30 33 32 5A 17 0D 34
30 30 39 31 30 31 31 34 30 33 32 5A 30 1A 31 18
30 16 06 03 55 04 03 0C 0F 49 6E 66 69 6E 65 6F
6E 49 6F 54 4E 6F 64 65 30 59 30 13 06 07 2A 86
48 CE 3D 02 01 06 08 2A 86 48 CE 3D 03 01 07 03
42 00 04 1C 17 67 64 B7 B7 68 46 0C 86 F1 EC 19
66 52 DD 1C 92 2C 95 B8 2E 9A E5 39 65 0B E5 F2
1F 60 B3 B8 C0 D9 B9 6A 13 0D CB 70 95 38 18 0F
D3 23 8F 31 80 90 5C 03 C8 29 B6 33 23 27 70 AC
8E FB F0 A3 58 30 56 30 0E 06 03 55 1D 0F 01 01
FF 04 04 03 02 00 80 30 0C 06 03 55 1D 13 01 01
FF 04 02 30 00 30 15 06 03 55 1D 20 04 0E 30 0C
30 0A 06 08 2A 82 14 00 44 01 14 01 30 1F 06 03
55 1D 23 04 18 30 16 80 14 B3 83 E1 AC 56 94 06
59 AF D8 AF 57 21 78 45 74 8E 0C 49 99 30 0A 06
08 2A 86 48 CE 3D 04 03 03 03 67 00 30 64 02 30
32 59 C4 36 61 86 C6 44 8D FE B8 A6 D3 A4 EA 08
6E 63 51 40 43 B3 05 4D 11 1E 88 3E D0 3A 39 60
BE 79 41 68 8B D8 4F 3E 29 D2 C7 B3 33 5C A9 FB
02 30 42 D7 FB 3D 45 67 07 57 35 B1 09 E6 82 49
D8 1F 77 A6 14 0D 1D 39 87 6E 59 01 B8 41 DC C8
82 BD 5E BA 92 69 5F A1 E7 68 26 B1 B1 AC DB 0E
AA 2B
Output to teste0e0.crt
======================================================== where as you attempt to read with the last command not a certificate but you ASCII encoded data. To the main topic: pi@yushevpi:~/git/linux-optiga-trust-m/bin $ wget "https://raw.githubusercontent.com/Infineon/optiga-trust-m/develop/certificates/Infineon%20OPTIGA(TM)%20Trust%20M%20CA%20300.pem" -O ifx_ca_certificate.pem
pi@yushevpi:~/git/linux-optiga-trust-m/bin $ ./trustm_cert -w 0xe0e1 -i ifx_ca_certificate.pem |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Thank you, that indeed looks a bit not as it should be, the reason could be non-standard metadata settings changed in the past, could you please run the following command and put the result here: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
I'll rebuild and add debug
|
Beta Was this translation helpful? Give feedback.
-
Any thoughts on above ? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
ok, I see now, the reason for this is that the command given to write the certificate to the object location contains a wrong offset value I've posted a bug report for your issue. |
Beta Was this translation helpful? Give feedback.
ok, I see now, the reason for this is that the command given to write the certificate to the object location contains a wrong offset value
From the log:
04 01 10 09 20 82 40 02 C5 E0 E1 BF 51 30 82 02 BD 30 82
, the valueE0 E1
is the target object ID, afterwards the offset comes (see SetDataObject command in the Solution Reference Manual), in your case it isBF 51
, which exceeds the boundary of the objects, thus you get an error.The reason for this is here uninitialized value for the offset, for the read operation the offset value is zeroed. In order to fix it in your lcoal version jsut initialize this value with 0, and it will be fine.
I've posted a bug report for your issue.