Multos Forums

   

ECC Elliptic Curve Diffie Hellman result truncated

Rank

Total Posts: 7

Joined 2013-04-17

PM

I’m currently working on an implementation using the ECC ECDH operation. I got everything to work in the debugger, except that the result of the operation (the shared key) is truncated. To be precise the first 2 bytes are always 0x0000. The remainder of the value corresponds to the expected value computed on the terminal/PC.

Is this a bug in the debugger, or what is happening?

(I’m now about to test it on a card to see if that does work as expected.)

     
Rank

Total Posts: 7

Joined 2013-04-17

PM

When trying this code on a card I get SCARD_E_NOT_TRANSACTED responses when ECC operations (key generation / ECDH) are involved.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Pim Vullers - 29 August 2013 07:35 PM

I’m currently working on an implementation using the ECC ECDH operation. I got everything to work in the debugger, except that the result of the operation (the shared key) is truncated. To be precise the first 2 bytes are always 0x0000. The remainder of the value corresponds to the expected value computed on the terminal/PC.

Is this a bug in the debugger, or what is happening?

(I’m now about to test it on a card to see if that does work as expected.)

This does look suspect. I’ll take a look and let you know.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Pim Vullers - 29 August 2013 08:44 PM

When trying this code on a card I get SCARD_E_NOT_TRANSACTED responses when ECC operations (key generation / ECDH) are involved.

This may be due to the following issue noted in the implementation report for M3 cards.

ECC Diffie Hellman: The memory allocated to the private key must be prime length * 2 even though the private key has length of prime. This is required to guarantee that the primitive executes successfully.

Try doubling the size of the private key buffer and see if that works - it needs to be 2*prime length.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Chris Torr - 30 August 2013 10:07 PM
Pim Vullers - 29 August 2013 07:35 PM

I’m currently working on an implementation using the ECC ECDH operation. I got everything to work in the debugger, except that the result of the operation (the shared key) is truncated. To be precise the first 2 bytes are always 0x0000. The remainder of the value corresponds to the expected value computed on the terminal/PC.

Is this a bug in the debugger, or what is happening?

(I’m now about to test it on a card to see if that does work as expected.)

This does look suspect. I’ll take a look and let you know.

OK, I think I’ve found the problem - its seems to be a problem with the compilation of the debugger. I’m just looking into solutions now. I’ll send you a copy to test when its ready.

     
Rank

Total Posts: 7

Joined 2013-04-17

PM

Hi Chris,

The application now works fine in the debugger. I’ve tested it thoroughly and everything works out.

However, when I load the application on the card and try to perform the same commands as in the debugger, things go wrong. I get CARD_NOT_TRANSACTED errors from the card reader/PCSC daemon.

When I drop the ECC calls from the code no errors occur.

According to the MIR the ML3 card should support ECC: http://www.multos.com/products/approved_platforms/MIR/multos_international/m3

My code is available at: https://github.com/credentials/sbcred_multos

Can you please help me figure out what’s going wrong?

Thanks,
Pim

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Hi, as mentioned earlier in the thread there is an issue on ML3’s with storage of the private key. You need to have a buffer twice the size of the actual key. So in ECC.h change

typedef unsigned char ECC_private_key[ECC_KEY_BYTES]

to

typedef unsigned char ECC_private_key[ECC_KEY_BYTES*2]

See if that helps. Also remember in the ALC that you need to select Strong Crypto functions in access_list.

 

     
Rank

Total Posts: 7

Joined 2013-04-17

PM

I tried this fix and it did not change the behaviour. I still get the card not transacted error.

Also, it’s not only ECDH that is failing. EC key generation fails as well on the card.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Please can you e-mail me the APDUs you are sending to the application.
Thanks.

     
Rank

Total Posts: 7

Joined 2013-04-17

PM

You can use the following commands to test:

SELECT:
00A404000673626372656400

INIT:
000100005D0014FFFFA2684FA063FD68E349415E0198116A42E8B30014FFFFA2684FA063FD68E249418CCD75C1B3D1D46D00010000010300290400000000000000000000000000000000000000010000000000000000000000000000000000000002

This INIT command calls the ECC key generation function and will respond with the generated public key.

ECDH:
0005000041001420B8EDFEFADFF92515380639449CFA31FFF22D2600290400000000000000000000000000000000000000010000000000000000000000000000000000000002

This ECDH command computes the ECC Diffie-Hellman operation for the given data.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

I have managed to get your INIT and DH functions to execute in card after making some code changes. Before accessing the contents of the APDU data in public, you need to call the function CheckCase. This validates the APDU structure and sets up the necessary offsets. If you don’t call it, in your example, APDU_buffer could contain anything.

e.g. For your init function, you are passing the domain parameters to use as the APDU data. This is an ISO Case 3 command.

case 0x01:
  if (!
CheckCase(3))
    
multosExitSW(ISO7816_SW_WRONG_PARAMS);

  
// Initialise the cards parameters and keys
  
initialise(APDU_buffer);
  
multosExit(); 

Have you been through the example loyalty application that is in the SmartDeck installation? I’d highly recommend it as it goes through these points. Sometimes the debugger lets you get away with things that the actual platforms don’t.

Also, instead of defining all your own macros for accessing primitives, why not download the multos.h file from the Developer Centre? The macros in this file implement the MULTOS C-API. As well as calling the primitives, the macros check the CCR and return appropriate status values to the caller.

     
Rank

Total Posts: 7

Joined 2013-04-17

PM

I’ve been through the example and already developed a big application (https://github.com/credentials/irma_card). This is only a small proof of concept application, and I forgot about these checks.

I’ve been using the header files provided by SmartDeck for my development thus far. However, the MEL assembly is slightly more flexible then the C macros, hence in the end I’ve had some parts of code written in assembly instead of using the macros. This finally resulted in copying the macros to my own header files.

I’ve added the CheckCase statements for all instructions, but I still get the CARD_NOT_TRANSACTED error. Could you please send me your ALU file? I have a developer card, so should be able to load it and test, to find out whether my card is also part of the issue.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Pim, I’ve e-mailed everything to you. Let me know how you get on.

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Here is a very simple working example of using the ECC primitives to generate a key and use Diffie Helman.

     
Rank

Total Posts: 1

Joined 2014-02-14

PM

Hi,

the new header file seems to be correct now, but I find the behaviour still strange:

Firstly, I generate a new key pair:
70 01 00 00 00 -> 57 ea 26 64 30 0c 3a 73 87 e1 89 f8 1a 71 a0 36 14 44 97 2d bd f0 37 01 2d a2 e3 25 8a 72 f3 e0 52 57 6d df 32 93 5d f3 40 c8 09 ca c8 25 fc 32 15 ef 42 47 0f 08 d0 82 cd 1d 5f 37 b3 7d c1 12 e5 d8 1b fd ca 25 08 c8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 00

Then I sign some data:
70 02 00 00 18 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 -> 00 8a a5 bf 2e 84 c1 c3 ac e4 a1 05 46 a9 53 4f d8 56 72 30 51 f2 b9 46 0c 0f 9f d0 75 ac 25 9f 39 40 34 28 33 2c 76 f8 1c 62 05 31 13 0e c5 fb 90 00

Now I try to verify the signature:
70 03 00 00 78 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 00 8a a5 bf 2e 84 c1 c3 ac e4 a1 05 46 a9 53 4f d8 56 72 30 51 f2 b9 46 0c 0f 9f d0 75 ac 25 9f 39 40 34 28 33 2c 76 f8 1c 62 05 31 13 0e c5 fb 57 ea 26 64 30 0c 3a 73 87 e1 89 f8 1a 71 a0 36 14 44 97 2d bd f0 37 01 2d a2 e3 25 8a 72 f3 e0 52 57 6d df 32 93 5d f3 40 c8 09 ca c8 25 fc 32 -> 90 ff

but it fails (90ff) and the Z flag is “1”.

Any idea? Do I use the correct input format?

Thanks,

Vojta

     
RankRankRank

Total Posts: 74

Joined 2012-02-21

PM

Hi,

There’s an error in my example application when generating the signature. In the call to multosEccGenerateSignature, the second argument should be

(BYTE*) & eccKeyPair.privateKey

Thanks for pointing out the problem. I’ll update the example.