Bruce, NFC is a *consumer* oriented solution. Such solutions by definition do not even try to solve all problems you describe. That the device would authenticate to the reader is out of scope in that realm. You should rather compare this to WLAN connections.
There are no share secrets as that does not scale to a 2 billion user level (2008). >From a security point of view it is though worth mentioning that - PIN codes stay in the device - Security operations are never performed without informaing/questioning the user =========================================== This is something existing smart card systems fail to achieve. =========================================== And again: human-related problems are much bigger and no crypto in the world will ever solve it. Anders ----- Original Message ----- From: "Bruce Barnett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 16, 2004 21:16 Subject: Re: [Muscle] NFC - A killer technology > 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 _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
