Digest Operations using SE050

[badhri_radhakri]

Hi Guys,

I have an input string say 1000 chars long and I'd like to generate a hash value for it. I initially used the DigestOneShot function by sending in the input string by chaining them. Unfortunately there is a limitation to the input APDU length of only 889 bytes total as per this Datasheet. So is it only possible to use Digest Init-Update-Final operations instead of DigestOneShot ? My input may go up to 2000 chars in the future. 

My master hardware is STM32 and target is SE050. I've created the 2 byte crypto object required for the Digest Init-Update-Final operations. Now my question is in what sequence do I call the Digest Init-Update-Final functions. Currently my code does the following (All below operations are performed session-less):

1. Soft reset

2. Select SE050 applet

3. Digest Init

4. Digest Update

5. Digest Final

For instance if I have more data to be updated, then should I do the steps 1 & 2 for each Digest Update or is it sufficient that I do the steps 1 & 2 only once? 

Edit: I created the crypto object required for the Digest operations. 

Object ID: 00 05

01: CryptoContext - CC_DIGEST

04: Crypto object sub-type - DIGEST_SHA256

Now when I call the Digest-init function, i'm able to initialize successfully. 

The response is 90 00

But when I call the Digest-update function with the input data, the chip throws me the "conditions not satisfied" response.

The response I get is 69 85 always. I double checked my input commands and they are according to the Digest-Update structure explained in datasheet. All the functions are called without sessions and communicated via I2C protocol. Am I missing any other key info here like is there a minimum size of input data that is required for the Digest-update function or can it handle any size of data every time ?

I've been working on this project for a while and asked couple of questions already here that were answered. I'd be glad if I get an idea about this too :smileyhappy:

[michaelsalfer · Accepted solution]

Hello,

trying to step in with a working example.

If you use the sss API layer all these steps are done automatically and you don't need to construct the APDU.

To replicate your use case: When you replace in the MW example ex_md the line

sss_digest_one_go(&ctx_digest, input, inputLen, digest, &digestLen);

with 

sss_digest_init(&ctx_digest);
sss_digest_update(&ctx_digest, input, inputLen);
sss_digest_finish(&ctx_digest, digest, &digestLen);

then the SSS API takes care to generate these APDUs which include digest init/update/final:

VCOM:INFO :Waiting for card ........

     smCom:INFO :APDU Tx> (Len=5)

                00 A4 04 00     00

     smCom:INFO :APDU Rx< (Len=20)

                6F 10 84 08     A0 00 00 01     51 00 00 00     A5 04 9F 65

                01 FF 90 00

     smCom:INFO :APDU Tx> (Len=21)

                00 A4 04 00     0F A0 00 00     03 96 54 53     00 00 00 01

                03 00 00 00     00

     smCom:INFO :APDU Rx< (Len=9)

                03 01 00 6F     FF 01 0B 90     00

     smCom:INFO :APDU Tx> (Len=5)

                80 02 10 25     00

     smCom:INFO :APDU Rx< (Len=6)

                41 82 00 00     90 00

     smCom:INFO :APDU Tx> (Len=15)

                80 01 10 00     0A 41 02 00     03 42 01 01     43 01 04

     smCom:INFO :APDU Rx< (Len=2)

                90 00

     smCom:INFO :APDU Tx> (Len=9)

                80 03 00 0B     04 42 02 00     03

     smCom:INFO :APDU Rx< (Len=2)

                90 00

     smCom:INFO :APDU Tx> (Len=21)

                80 03 00 0C     10 42 02 00     03 43 0A 48     65 6C 6C 6F

                57 6F 72 6C     64

     smCom:INFO :APDU Rx< (Len=2)

                90 00

     smCom:INFO :APDU Tx> (Len=11)

                80 03 00 0D     06 42 02 00     03 43 00

     smCom:INFO :APDU Rx< (Len=38)

                41 82 00 20     87 2E 4E 50     CE 99 90 D8     B0 41 33 0C

                47 C9 DD D1     1B EC 6B 50     3A E9 38 6A     99 DA 85 84

                E9 BB 12 C4     90 00

     smCom:INFO :APDU Tx> (Len=9)

                80 04 10 28     04 41 02 00     03

     smCom:INFO :APDU Rx< (Len=2)

                90 00

      VCOM:INFO :Closing connection

Kind regards,
Michael

[badhri_radhakri]

Hi michaelsalfer‌, 

Thanks for helping me out with this. Actually the mistake was on my I2C packet part. The PCB byte was causing this issue. Now that I've corrected it and I'm able to update the input data for generating the hash value. Thanks a lot!

[Kan_Li]

Hi ,

What is the APDU command you set up for Digest-update function? Is it possible sharing for a review?

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.
-------------------------------------------------------------------------------

[badhri_radhakri]

Hi Kan_Li‌ the issue was with the incorrect PCB byte. Now I've corrected it and its working fine. The APDU commands were correct all the time :smileyhappy:

Thanks a lot!