That's the 1-meg signed browser plugin that harningt was talking about...installing that is about as painful as installing Flash, and it works with IE, Firefox (Windows, Mac & Linux), and Safari.
Actually, those with existing devices (for example, the 6 million people in the US with PIV or CAC cards) can use those at no cost. The tokens for sale on the site are for those who don't already have one.
Age would be one of the pieces of optional metadata that can be provided to the relying party if it is ever collected...if, for example, a web site wanted to authenticate someone's age but the provider did not provide that about a user, it would reject the authentication on those grounds. The TrustBearer site only asks for your nickname and email address, so that's all it could conceivably release to the relying party, and I don't think the email address is even released...and so far, it seems like that's sufficient for every site that I've tried.
Regarding 50-year-old men posing as 14-year-old girls, an OpenID provider could assert that it does indeed verify the age of its users. If it became known that a provider was lying about this, that provider would be quickly blacklisted (or un-whitelisted) from sites that cared about age. This is sort of analogous to the logic behind why you can't use a school ID to buy booze. The school says that you are you, and that's cool for many situations, but it isn't considered to be as authoritative as a credential issued by the BMV.
Actually, MoC (which is preferred over Match on Reader, and equivalent FAPP to match on device) stores the fingerprint on the card itself -- in write-only memory, so it can't ever be read...it can only be used by the card/device itself for matching a live swipe.
It's cool that you mention public keys, because that's really what this is all about. When you match your print on the card/device, it allows your private key to be used for a decryption/signature operation, which is what really used to authenticate you -- just like PKI with SSH. Hardware security devices also get around the problem of exposed private keys, because like the biometric template, smart cards always store the private key in write-only memory -- or sometimes, in memory that can't be read or written to from the outside -- they just support an on-card key generation procedure that returns the public key, but keeps the private key locked away, so it has never left the card. And even if the key somehow did get compromised, revocation is just as easy as revoking a "soft" key on your hard drive...just generate a new keyand enroll for a new certificate to match it.
We may have a solution (free, of course) that will do exactly what you're asking for. Write info@trustbearer.com with "TrustBearer Token" in the subject and mention this post, and we'll hook you up.
TrustBearer supports two fingerprint readers: one supports both Match on Card (MoC), Match on Reader, and Match on Server. The other is a standalone device that matches your fingerprint on the device itself.
The Match on Server solution is what you are describing, but this raises privacy, policy and integration concerns. In the other two situations, the fingerprint "image" is stored in write-only memory on the device. When you swipe your finger, the image goes straight to the device which then tries to match it against the stored copy. If it succeeds, it sets an internal flag that will allow you to use the private key (which may also require a prior PIN verification if three-factor authentication is desired). The private key is linked to a public key in a certificate that is sent to the server...so your biometrics stay private.
This may be an issue with many OpenID sites, but this one in particular dodges your worries.
Since the certificate you pass to the provider is never released to the relying party (and which regardless doesn't need to have anything tying your identity to it), you are even more anonymous than with traditional username/password authentication -- the only one who knows who you are is you...the provider just knows you by your public key, and the relying party only knows that the provider consistently says that you are http://openid.trustbearer.com/yourfakename.
While I agree that this doesn't even remotely resemble MAC address authentication, there are a few things that seem to be misunderstood...
First, the TrustBearer OpenID site doesn't currently support one-time password (OTP) devices like the one you're referring to...at the moment it supports public key authentication, the kind that web servers use for SSL.
As far as OTP being broken, it would be possible for a phishing site to ask you to enter your credentials, then submit it to the real site before the validity window expires and successfully impersonate you. As the window is usually on the order of a few minutes, this doesn't really provide any better phishing protection than regular username/passwords. It does, however, enforce a policy that would prevent anyone from being able to guess your password.
Another difference between OTP and public key authentication is that for OTP to work, the server has to know something secret about your particular device for it to be able to know what your current password is, which means that you would be locked into a single provider (usually the manufacturer)...but with public key authentication, there is no such constraint.
I'm not sure if you're referring to the TrustBearer Security Token for sale on the site (which is/not/ the only supported device...for example, all US-govt PIV and CAC cards will work), or the PayPal device...but as this seems to be a common misconception, I'd like to clear this up.
The TrustBearer Security Key is a cryptographic device (with drivers on Windows update) that goes in a USB port. It uses asymmetric cryptography to decrypt a nonce sent by the provider to prove that the user owns the public key associated with the account. It is for all practical purposes a smart card and reader combined.
The PayPal/RSA SecureID/Verisign token is a one-time password (OTP) device. It shows a different number every n seconds, which you type in along with your username and password to authenticate.
As harningt mentioned in another thread, such devices could in principle be supported by the TrustBearer framework if there was significant demand, but it is currently geared towards asymmetric challenge-response authentication.
Right. And in this case, the certificate never even leaves the provider...so no worries about relying parties getting personal information aside from the nickname that you provide when signing up.
It's true -- extra software is needed...but the same is true of any peripheral connected to your computer.
Any cryptographic device will need to be attached to the computer, and software will need some way to talk to it. Since the VeriSign/PayPal token is a one-time password token, the back-end "shares a secret" with the token, no direct communication between that device and the computer is necessary, except through you via keyboard input.
However, with a smart card or other security device, the private keys cannot leave the device, and don't exist on a server anywhere. To prove that you "own" the certificate that you present, you encipher some data with that private key, which the OpenID provided then deciphers with your public key. If it's the same data that it sent you, then you own the key and you are authenticated.
Regarding installing "extra software", most card readers have drivers in Windows update, and are standards-compliant so they work out of the box on Mac/Linux. So installing the "extra software" involves clicking "Next" a few times, then "Finish" the first time you plug your reader in...sort of like what you would expect the first time you plug any regular USB storage drive into your computer.
Slashdot Mirror
That's the 1-meg signed browser plugin that harningt was talking about...installing that is about as painful as installing Flash, and it works with IE, Firefox (Windows, Mac & Linux), and Safari.
Also, where's the Java that you're referring to?
Age would be one of the pieces of optional metadata that can be provided to the relying party if it is ever collected...if, for example, a web site wanted to authenticate someone's age but the provider did not provide that about a user, it would reject the authentication on those grounds. The TrustBearer site only asks for your nickname and email address, so that's all it could conceivably release to the relying party, and I don't think the email address is even released...and so far, it seems like that's sufficient for every site that I've tried.
Regarding 50-year-old men posing as 14-year-old girls, an OpenID provider could assert that it does indeed verify the age of its users. If it became known that a provider was lying about this, that provider would be quickly blacklisted (or un-whitelisted) from sites that cared about age. This is sort of analogous to the logic behind why you can't use a school ID to buy booze. The school says that you are you, and that's cool for many situations, but it isn't considered to be as authoritative as a credential issued by the BMV.
Actually, MoC (which is preferred over Match on Reader, and equivalent FAPP to match on device) stores the fingerprint on the card itself -- in write-only memory, so it can't ever be read...it can only be used by the card/device itself for matching a live swipe.
It's cool that you mention public keys, because that's really what this is all about. When you match your print on the card/device, it allows your private key to be used for a decryption/signature operation, which is what really used to authenticate you -- just like PKI with SSH. Hardware security devices also get around the problem of exposed private keys, because like the biometric template, smart cards always store the private key in write-only memory -- or sometimes, in memory that can't be read or written to from the outside -- they just support an on-card key generation procedure that returns the public key, but keeps the private key locked away, so it has never left the card. And even if the key somehow did get compromised, revocation is just as easy as revoking a "soft" key on your hard drive...just generate a new keyand enroll for a new certificate to match it.
Or did I just totally misread that?
We may have a solution (free, of course) that will do exactly what you're asking for. Write info@trustbearer.com with "TrustBearer Token" in the subject and mention this post, and we'll hook you up.
The Match on Server solution is what you are describing, but this raises privacy, policy and integration concerns. In the other two situations, the fingerprint "image" is stored in write-only memory on the device. When you swipe your finger, the image goes straight to the device which then tries to match it against the stored copy. If it succeeds, it sets an internal flag that will allow you to use the private key (which may also require a prior PIN verification if three-factor authentication is desired). The private key is linked to a public key in a certificate that is sent to the server...so your biometrics stay private.
To unlock the private key on the device that you have, you need to know the PIN...so that's two-factor.
For the biometric devices, there are two options: either the biometric replaces the PIN, or you need to swipe and type.
This may be an issue with many OpenID sites, but this one in particular dodges your worries.
Since the certificate you pass to the provider is never released to the relying party (and which regardless doesn't need to have anything tying your identity to it), you are even more anonymous than with traditional username/password authentication -- the only one who knows who you are is you...the provider just knows you by your public key, and the relying party only knows that the provider consistently says that you are http://openid.trustbearer.com/yourfakename.
First, the TrustBearer OpenID site doesn't currently support one-time password (OTP) devices like the one you're referring to...at the moment it supports public key authentication, the kind that web servers use for SSL.
As far as OTP being broken, it would be possible for a phishing site to ask you to enter your credentials, then submit it to the real site before the validity window expires and successfully impersonate you. As the window is usually on the order of a few minutes, this doesn't really provide any better phishing protection than regular username/passwords. It does, however, enforce a policy that would prevent anyone from being able to guess your password.
Another difference between OTP and public key authentication is that for OTP to work, the server has to know something secret about your particular device for it to be able to know what your current password is, which means that you would be locked into a single provider (usually the manufacturer)...but with public key authentication, there is no such constraint.
I'm not sure if you're referring to the TrustBearer Security Token for sale on the site (which is /not/ the only supported device...for example, all US-govt PIV and CAC cards will work), or the PayPal device...but as this seems to be a common misconception, I'd like to clear this up.
The TrustBearer Security Key is a cryptographic device (with drivers on Windows update) that goes in a USB port. It uses asymmetric cryptography to decrypt a nonce sent by the provider to prove that the user owns the public key associated with the account. It is for all practical purposes a smart card and reader combined.
The PayPal/RSA SecureID/Verisign token is a one-time password (OTP) device. It shows a different number every n seconds, which you type in along with your username and password to authenticate. As harningt mentioned in another thread, such devices could in principle be supported by the TrustBearer framework if there was significant demand, but it is currently geared towards asymmetric challenge-response authentication.
Right. And in this case, the certificate never even leaves the provider...so no worries about relying parties getting personal information aside from the nickname that you provide when signing up.
It's true -- extra software is needed...but the same is true of any peripheral connected to your computer.
Any cryptographic device will need to be attached to the computer, and software will need some way to talk to it. Since the VeriSign/PayPal token is a one-time password token, the back-end "shares a secret" with the token, no direct communication between that device and the computer is necessary, except through you via keyboard input.
However, with a smart card or other security device, the private keys cannot leave the device, and don't exist on a server anywhere. To prove that you "own" the certificate that you present, you encipher some data with that private key, which the OpenID provided then deciphers with your public key. If it's the same data that it sent you, then you own the key and you are authenticated.
Regarding installing "extra software", most card readers have drivers in Windows update, and are standards-compliant so they work out of the box on Mac/Linux. So installing the "extra software" involves clicking "Next" a few times, then "Finish" the first time you plug your reader in...sort of like what you would expect the first time you plug any regular USB storage drive into your computer.