BitShares Forum
Main => General Discussion => Topic started by: Gentso1 on December 29, 2014, 05:18:26 pm
-
http://cointelegraph.com/news/113210/hyprkey-almost-unhackable-authentication (http://cointelegraph.com/news/113210/hyprkey-almost-unhackable-authentication)
https://www.hyprkey.com/ (https://www.hyprkey.com/)
How secure and cool is this. It uses a phone,password and bio-metric scanner. Doesn't store any info and each scan generate's a unique key. No yubikey,2fa,password manager needed.
Bitshares mobile wallet+hyprkey+liquid exchange=merchant adoption=mass adoption
-
Great find!
"HYPR-3 is an open platform. All 3rd parties may integrate."
!
-
Great find!
"HYPR-3 is an open platform. All 3rd parties may integrate."
!
mailed ;)
-
Awesome. I think it would be really helpful if we could compete with the convenience of existing payment options. Based on what was described in the article about the opposing viewpoints for the evolving payment industry, we would be the best of both worlds if we could be as easy to use as an Apple Pay. Convenient + Secure + low fees = Amazing.
-
+5%
-
Good find, I just sent an email to request details on the cryptography and how revocation works. I have a method for doing it completely on the blockchain without a curator if it requires one then you might as well use yubikey.
-
http://cointelegraph.com/news/113210/hyprkey-almost-unhackable-authentication (http://cointelegraph.com/news/113210/hyprkey-almost-unhackable-authentication)
https://www.hyprkey.com/ (https://www.hyprkey.com/)
How secure and cool is this. It uses a phone,password and bio-metric scanner. Doesn't store any info and each scan generate's a unique key. No yubikey,2fa,password manager needed.
Bitshares mobile wallet+hyprkey+liquid exchange=merchant adoption=mass adoption
Potential to be very secure. More secure than bank security.
This combined with multi-sig 3 of 4 would be secure enough for almost anyone as long as the 4th key is held by a secure third party.
The questions are in the implementation. Is it open source? Where is the source code? Multi-factor authentication is a must but not enough details on the mechanisms of biometrics. Some forms of biometrics aren't currently possible to fake while others are easy to fake (like fingerprint).
-
I'd bet money that this doesn't work as well as advertised. Assuming all the crypto is legit etc, the real issue becomes how easy is it to fake the biometric aspect which they gloss over.
They make some fascinating claims.. impervious to malware.. hard to imagine that claim for starters.
-
They are apparently going for FIPS 140-2 L3 certification and the tokens are generated via RFC-6238, which is the gold standard. Still requires central curation so no big innovation. Just a better yubikey.
-
Here's the reply I got from the company:
Hi Charles,
I believed we replied on Twitter that our white paper is coming out in a few weeks that is detailing the cryptography that is being used within our device.
To answer your other questions, If Bob has a working sticker on his phone and loses his phone, he can pair the device with another phone when he gets it. The HYPR-3 device can be paired with multiple devices such as mobile phones, laptops, etc... A main implementation of HYPR-3 is so that our enterprise customers can use the device for authentication and effectively replace their RSA tokens with a biometric solution.
This is how a basic authentication works after a user has configured their HYPR-3:
1. A user does an action where authentication is required via HYPR-3
2. User's mobile device prompts them to swipe their finger on the HYPR-3 device
3. User swipes their finger and it gets verified on the HYPR-3 device
4. An encrypted message with a TOTP token is sent from the HYPR-3 device to the User's mobile phone and it is then transmitted to the HYPR-3 Cloud (this is either SAS or On Premise)
5. The TOTP token from HYPR-3 is validated against the TOTP on our server.
6. Once the TOTP is verified, the HYPR-3 cloud can return a session token or a simple message that says the authentication succeeded.
A few points to remember:
1. The user's fingerprint data never leaves the HYPR-3 device.
2. The TOTP token can only be retrieved from the HYPR-3 device upon a successful fingerprint authentication.
Some security info:
1. Here is the fingerprint reader that we use: http://www.fingerprints.com/products/fpc1080a-swipe/
2. Asymmetric encryption is done using AES encryption and ECDSA with 256 bit keys
3. The TOTP specs are outlined in RFC-6238
4. The microprocessor we are using on our board has a TRNG
Let me know if you have additional questions prior to the release of our White Paper. You can email me at bojan@hyprkey.com.
Thanks,
Bojan Simic
CTO @ HyprKey
Having a fingerprint unlock the TOTP is a nice feature and also having a TRNG on device is pretty solid. Adding a blockchain into the account management side of things would totally decentralize the device. It's almost perfect.
-
sounds promising +5%
BTW: https://www.hyprkey.com/hyprkey-password-manager/
-
sounds promising +5%
BTW: https://www.hyprkey.com/hyprkey-password-manager/
I saw that. It would be nice to replace lastpass.
In terms of blockchain management, here's a rough idea of the scheme.
Alice wants to setup two factor authentication with Bob's server. Alice has a device like Hyperkey that can generate authentication tokens from a particular seed.
Bootstrap:
- Hash device specific to create a unique device ID (DHashID)
- Bob's server creates a UUID (BHashID)
- Request alice and bob's public keys
- Generate a seed (say 128 bit) for use uniquely to Bob's server
- Encrypt the seed with alice's public key (EAliceSeedCopy)
- Encrypt the seed with bob's public key (EBobSeedCopy)
- Insert a data record into the blockchain (HashID, BHashID) -> {EAliceSeedCopy : EBobSeedCopy}
Authentication:
- The device retrieves the encrypted seed from the blockchain entry
- The device decrypts the seed in memory and uses a desired OTP protocol
- Bob performs the same steps
- Tokens match
- Alice proves she can reverse the device hash to bob (either directly or via a ZKP)
- Server issues access credentials to alice for time amount X
- Both parties purge seeds from memory
This design means that every website has a unique access seed, the device itself stores no credentials (however it's needed for authentication), and there is no central curation. If alice loses her device, one could setup a revocation and transfer protocol as follows:
- Alice creates a file containing a set of PII that's hard to guess
- Alice creates a passphrase
- Alice takes the PII and encrypts with the passphrase via some cipher like AES
- Alice hashes the result
- Alice stores the hash on blockchain alongside some index for lookup and a label as a revocation and transfer entry
- If Alice loses her hardware (or we could also extend to a public-private keypair), then Alice issues a revocation and transfer transaction <encrypted hash reversal, new ID to bind old credentials to, new revocation and transfer hash>. Basically all she has to do is pick a new passphase and a new ID to bind the old one to. In the case of a hardware device, it would be a new hashed hardware ID.
- Protocol transfers all rights, reputation, and responsibilities to the new ID
Now we can lose our device or keypair and still recovery it in a decentralized way.
-
sounds promising +5%
BTW: https://www.hyprkey.com/hyprkey-password-manager/
I saw that. It would be nice to replace lastpass.
In terms of blockchain management, here's a rough idea of the scheme.
Alice wants to setup two factor authentication with Bob's server. Alice has a device like Hyperkey that can generate authentication tokens from a particular seed.
Bootstrap:
- Hash device specific to create a unique device ID (DHashID)
- Bob's server creates a UUID (BHashID)
- Request alice and bob's public keys
- Generate a seed (say 128 bit) for use uniquely to Bob's server
- Encrypt the seed with alice's public key (EAliceSeedCopy)
- Encrypt the seed with bob's public key (EBobSeedCopy)
- Insert a data record into the blockchain (HashID, BHashID) -> {EAliceSeedCopy : EBobSeedCopy}
Authentication:
- The device retrieves the encrypted seed from the blockchain entry
- The device decrypts the seed in memory and uses a desired OTP protocol
- Bob performs the same steps
- Tokens match
- Alice proves she can reverse the device hash to bob (either directly or via a ZKP)
- Server issues access credentials to alice for time amount X
- Both parties purge seeds from memory
This design means that every website has a unique access seed, the device itself stores no credentials (however it's needed for authentication), and there is no central curation. If alice loses her device, one could setup a revocation and transfer protocol as follows:
- Alice creates a file containing a set of PII that's hard to guess
- Alice creates a passphrase
- Alice takes the PII and encrypts with the passphrase via some cipher like AES
- Alice hashes the result
- Alice stores the hash on blockchain alongside some index for lookup and a label as a revocation and transfer entry
- If Alice loses her hardware (or we could also extend to a public-private keypair), then Alice issues a revocation and transfer transaction <encrypted hash reversal, new ID to bind old credentials to, new revocation and transfer hash>. Basically all she has to do is pick a new passphase and a new ID to bind the old one to. In the case of a hardware device, it would be a new hashed hardware ID.
- Protocol transfers all rights, reputation, and responsibilities to the new ID
Now we can lose our device or keypair and still recovery it in a decentralized way.
Now we are talking buddy! +5%
-
http://www.tomshardware.com/news/german-minister-fingerprint-cloned-photos,28268.html (http://www.tomshardware.com/news/german-minister-fingerprint-cloned-photos,28268.html)
-
Ideally this scheme could be implemented in software and leverage the TPM ecosystem. Waiting on rivetz's API to see I'd there is enough meat on the bone.