Smart Cards and Secure Element中的主题 Re: SE050 returns wrong length when generating ECC signature

SE050 returns wrong length when generating ECC signature

djdirkj — Thu, 01 Jun 2023 10:50:28 GMT

Hi,

I've been working with the #SE050 for ECDSA signature generation and I'm noticing that it sometimes returns a wrong length, and it is occurring in the ASN1.DER part of the response.

30 => SEQUENCE

34 => 52 bytes

02 => INTEGER

18 => 24 bytes

55 9e f2 42 37 34 a7 43 9c 7d
4d d5 d8 63 41 95 a8 da 51 df
2d 6b ae -> 23 bytes?

02 => INTEGER
18 => 24 bytes

6e 4c 69 ee 62 9a 8f cc aa cc
03 02 bb 31 9d ad 83 2a 3e bf
a6 43 ce df -> 24 bytes

90 00

Another fault case

41 82 00 37 30 35

02 18
4a 59 98 83 45 6b 5c c4 79 c1
c8 c4 98 0a ae b8 db 60 f3 c5
1e 29 05 67

02 19
00 f9 75 95 a4 33 cb 9c 13 47
8b 43 eb 96 c5 34 a4 8b bb 0d
a1 06 ae 34

90 00

I'm curious if this is a known issue, it is very troublesome.

Re: SE050 returns wrong length when generating ECC signature

Kan_Li — Fri, 02 Jun 2023 02:30:08 GMT

Hi @djdirkj ,

Is your application based on the latest MW for SE05x? or just a demo out of the MW? Which platform is using with SE050? Would you please tell me more details about the SE050, such as variant, OEF ID, etc., I will try to reproduce this issue here.

Thanks for your patience!

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

Re: SE050 returns wrong length when generating ECC signature

djdirkj — Fri, 02 Jun 2023 08:59:52 GMT

Hi @Kan_Li ,

we are not using the MW from NXP, we have developed our own communication stack for the SE050. I'm not quite sure what you mean with "platform" but we are using a microcontroller to communicate with the SE050. I think it's good to understand that the response I provided above was measured directly on the I2C lines by means of a logic analyzer, there was interference by any software at this point.

The variant we are using is the SE050A2, and the applet version is 3.1.1. Where can I find the OEF ID?

Thanks.

Re: SE050 returns wrong length when generating ECC signature

Kan_Li — Mon, 05 Jun 2023 02:45:21 GMT

Hi @djdirkj ,

Thanks for the information! Actually supporting a custom MW is just out of my service range, but anyway, your issue is most likely a software issue, and you may check it in the APDU spec and T=1 Over I2C, and both of them can be verified with the demos out of our MW. Please refer to "simw-top/doc/demos/se05x/se05x_GetAPDUBuffer/Readme.html" and use it to check if your APDU command is constructed correctly, and please also use the demo of "simw-top/doc/demos/apdu_player/Readme.html" and check if your APDU command was sent to SE05x correctly.

BTW, may I have your concern using our MW? Even if the MCU you selected is not supported by the latest version, porting should cost less time than developing a custom MW.

For porting , you may refer to the Nano package which just contain the least components needed, and we also provide a general porting guide for reference, please kindly refer to the following for details.

https://github.com/NXPPlugNTrust/nano-package

https://www.nxp.com/docs/en/application-note/AN12448.pdf

Hope that helps,

Have a great day,
Kan

Re: SE050 returns wrong length when generating ECC signature

djdirkj — Wed, 05 Jul 2023 13:55:30 GMT

Hi @Kan_Li ,

most likely it was a software issue, but I have many boards lying around so I can't be too sure.

The main reason that we don't use the nano-package is that at the time we started using the SE050 (end 2020/beginning 2021) there was no nano-package available. And the other MW was using a massive amount of stack (>8KB) which was completely unacceptable. So, by the middle of 2021 we had a minimal implementation of the communication stack. We wanted to launch our product in 2022, but we got sidetracked due to issues. NXP launched the nano-package somewhere in 2022, you were just too late for us. And still we will not use the nano-package, our implementation is according to our philosophy and it is flexible enough to be used with secure elements from other vendors not only NXP. Being flexible is one of the important lessons that the supply chain issues tought everyone.