> Since I to some extent work with this I may provide some answers.
> NFC's main contribution is really "only" to initiate a secure WLAN,
> Bluetooth, or UWB link between a smart device an a contact point
> of some kind. A possible session state is only in the link.
One thing I am not clear about is how does the device authenticate the reader?
As I understand it in the smartcard world,, there is the EXT AUTH command that does
this. But how it does it is vague - and I guess left up to the vendor.
I'm not sure what standards exist for this phase.
If a shared secret key is used, then how is it installed and modified?
Are there risks involved in this process?
And if an asymetric key is used, how are the CA's set up, and does the card verify the
cert on the reader? And vice versa?
> I am also pretty sure that RFID systems are vulnerable to DoS
> attacks as is probably valid for all RF based systems.
Yes, but there may be others ways than just brute power.
One can initiate a sesison, and never follow through.
Asking a NFC device to do excessive crypto may drain the battery.
>
> It is likely that an initiation could be hijacked if you have a
> modified highly sensitive device. OTOH this is seldom of
> major �nterest unless you want to pay somebody other's bills
> or be first in a passport line.
Depends upon the application, doesn't it? And these don't really exist
yet. Here's a forced example, not one that is likely, but one that
stresses the system:
Two idential twins, born on the same day, and both choose a PIN based
on their birthday. Both try to enter a secure area. One has the proper
credentials, and the other does not. And the biometrics is based on
facial features, which in this case is nearly identical.
I'm not a Biometric guru, and having guessable PIN's is a dumb policy.
But it could happen.
> Regarding Man-in-the-Middle attacks I think these are highly
> dependent on the application protocol. If the application uses
> SSL client auth there should be small chances to succeed.
> Although overkill IMHO, SSL client auth could probably
> be used even for access control.
Between the NFC token and the reader?
Here's another example:
Say the reader and the token use a shared key. So all tokens have the
same key to do the EXT AUTH phase.
Person A and B both work for the same company, and have tokens for the
company. Person A is trying to pretend to be person B, who is right
behind him. Let's say person A is normally denied access to the door.
Reader and Person A's token authenticate each other - knowing the
site-specific key. Reader then asks for the user credentials and sends
a challenge to A. A has a modified reader on his token, and sets up a
session between himself and B. A then forwards the challenge to B, who
replies with B's credentials (signing the challenge with their private
key). A forwards this to the reader who thinks A is now B.
Person A could also be a bogus access system. Anyone who knows the
site-specific symmetric key can set up a "Trojan Reader."
At least with the existing UserCert MUSCLEcard mechanism, this is a
potential problem
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
