Subject: [eap] draft-urien-eap-smartcard-06.txt

From: Pascal Urien <[email-masked]>
Date: Thu, 19 Aug 2004 19:33:17 +0200

Hi Everybody,

   A new version of draft  draft-urien-eap-smartcard has been posted to the 
IETF
   server and should be available in a few days.

   It is already available at

   http://www.infres.enst.fr/~urien/security/draft-urien-eap-smartcard-06.txt

   The goal of this proposal is to fully compute (when possible !)  EAP 
methods in smartcards.
   According to particular constraints like for example IEEE 802.1X timeouts
   or Unix-time used in EAP-TLS, some (minor) adaptations may be needed.

  Therefore we believe that  this work is an interesting topic for the EAP 
task force.

  As an illustration we have recently tested the 1° EAP-TLS smartcard 
implementation.

   More technical information may be found at:

   http://www.infres.enst.fr/~urien/security/

   Pascal Urien.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Thomas Otto <[email-masked]>
Date: Fri, 20 Aug 2004 18:00:22 +0200

Hi Pascal,

I just had a look at your website ... 
Under the headline "the first EAP-TLS smartcard is operational 
in the ENST Wi-Fi network" you provide an ethereal packet dump of 
a full EAP-TLS authentication.
I measured the total time of this conversation. The time difference between
EAP-Request/Identity at 17:46:21 and EAP-Success at 17:46:58, are 
37 seconds.

More precisely, the client needs almost 30 seconds to send
ClientKeyExchange, CertificateVerify, and ChangeCipherSpec 
(in frame 52), where I remember ClientKeyExchange requires 
the 48 byte premaster secret. (which requires expensive 
computations ..)

So, is there hope for a speedup or is EAP-TLS not suitable for the 
EAP smartcard? How much Java influences this duration?

In contrast to this, as answer to "Are smartcards performances 
sufficient ?" we get the information, "Usually smart
cards include crypto-processors that compute the RSA 2048 bits
algorithm in less than 0,5s." 

This is great, so I suppose the card above lacks of such a
crypto-processor ? 

May I compare this to the running time of my implementation of 
EAP-PSK, which took for a full authentication only 0.75 seconds.
There is a strange 0.25 second delay between Identity Request and 
Response, so essentially we have 0,5 seconds for the protocol.
By the way, the notebook used for this test was nothing special, just a
4year old 400 MHz machine ;-)

Thomas

References
[1] http://www.infres.enst.fr/~urien/security/eap-tls-trace.pdf
[2] http://t13.mine.nu/EAP-PSK/020604-eappsk.pcap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Pascal Urien <[email-masked]>
Date: Fri, 20 Aug 2004 18:54:19 +0200

Hi Thomas

>EAP-Request/Identity at 17:46:21 and EAP-Success at 17:46:58, are

That's correct.

>the 48 byte premaster secret. (which requires expensive

This step cost around 1x RC4, 3x  RSA-1024 and about
  1000 x MD5&SHA1 512bits- blocks computation.

Most of the time is spent in digests functions

>EAP smartcard? How much Java influences this duration?

Usually digests functions are not supported by crypto processors
and are directly computed by 8 bit micro-controllers, that why they
are slow.

Some crypto algorithms like RC4, HMAC-MD5, HMAC-SHA1, TLS-PRF
are written in java card language. The solutions in order to dramatically
decrease the computing time are the following

- using smart cards with crypto processors supporting digests functions
- defining java card API for HMAC-MD5, HMAC-SHA1 and TLS-PRF
   (in progress ...)

>algorithm in less than 0,5s."

All crypto processors supports RSA. RSA is not an issue for
smart cards.

>This is great, so I suppose the card above lacks of such a

As i mentioned it above, RSA is not an issue. Digests functions
are the main bottleneck performances

>4year old 400 MHz machine ;-)

Smartcard is usually a 10 MHz 8bit micro-controller including a 
crypto-processor..

AES is supported by javacard 2;2. I have not yet performances figures for
EAP-PSK, it seems compatible with existing components.

>Thomas

Pascal

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 20 Aug 2004 19:25:46 +0200

>the 48 byte premaster secret. (which requires expensive 

It is FULL TLS. That means you will not see all these messages in 
TLS-PSK :).
The high latency here is because of the PRF (see later)

>This is great, so I suppose the card above lacks of such a

The card used in our test needs between 100 and 500 ms for RSA operations.
When you use a card handle SHA1 and MD5, the PRF will be negligeable. 
Take the example: RSA sign 342 bytes/s and verify 3287 [Rescorla] 
whereas SHA1 do 22838 Kbytes/s.

>4year old 400 MHz machine ;-)

Please, when you compare 4year old 400 MHz machine, do it but not with a 
VERY weak support like the smart card that has in our test the following 
properties: CPU 8 bits, RAM 2304 bytes, ROM 96 Kbytes, E2PROM 34 Kbytes, 
Max. Clock 8 MHz, Max Data Rate 424 kbit/s.

Add to that:

1) The weak smart card does not have also SHA1 and MD5 co-processor and 
thus the PRF-TLS representes about 25% from the global performance. 
Another 15% for the digest and 12 to 28% for data transfert. More info 
are available at 
http://www.infres.enst.fr/~urien/security/aswn2004-urien.pdf

2) You compare the EAP-PSK to FULL EAP-TLS, but you forget to do it with 
EAP-TLS-PSK.
Rescorla used in SSL and TLS book a Pentium II 400 for benchmarkink TLS, 
[machine equivalentto your one :)]. The Resumed Handshake (The 
equivalent of TLS-PSK) takes between 0.0028 and 0.0038 seconds (see 
Rescorla, Page 213, Figure 6.26).

Badra