OnlyKey Features
The primary benefit to having an OnlyKey is that instead of having to remember all of your passwords you can just remember one 7 - 10 digit PIN. You can set 12 unique 32 character passwords along with the usernames and even two-factor authentication to your OnlyKey. This way whenever you need to log in you just detach the OnlyKey from you keyring and enter your PIN to unlock your passwords. The Onlykey automatically types them into the login fields for you with the press of a button.
Wouldn't it be nice to know that your data is protected, and if you are in a pinch or forced to give up your PIN there is an easy way to make sure that your data does not get into the wrong hands. That is what the Self-Destruct feature is all about. You set this PIN code whenever you first set up your OnlyKey and then if you or anyone else ever enters it the OnlyKey wipes all of the sensitive data you have stored on it. More information on this feature is available in the [FAQ] (https://github.com/onlykey/OnlyKey-Firmware/wiki/FAQs).
Ever since Truecrypt the idea of plausible deniability has been fascinating to me. OnlyKey allows the use of a hidden profile and a fake profile that essentially provides a cover story. The fake profile can be activated and the goal of this feature is that proof that the hidden profile even exists is impossible to prove. This way you can plausibly deny that the OnlyKey uses encryption. Is it just a basic password manager or is there another hidden profile that is only activated if you know the secret PIN? More on this feature in the [FAQ] (https://github.com/onlykey/OnlyKey-Firmware/wiki/FAQs).
When it comes to hardware security there are terms such as tamper resistant, tamper proof, secure elements. These terms are mostly marketing terms as anyone with in depth knowledge of hardware security understands there is no such thing as tamper proof and tamper resistant can mean something as simple as the device being coated in plastic that can easily be removed. The National Institute of Standards and Technology has established some standards for the SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES in the publication [here] (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf). This standard defines 4 security levels.
A simplified explanation of these levels can be found on [wikipedia] (https://en.wikipedia.org/wiki/FIPS_140-2) (Notice that even the highest security level is not tamper proof)
While we do not plan on pursuing FIPS certification we can attest that some of the requirements of FIPS certification are met such as using at least one approved algorithm (FIPS 140-2 Level 1 - AES-256 is an approved algorithm). The coating of the OnlyKey would be difficult to remove and removing it would likely result in evidence that it was tampered with (FIPS 140-2 Level 2).
In addition to this, we enable the [Kinetis flash security] (http://cache.nxp.com/files/microcontrollers/doc/app_note/AN4507.pdf) the first time the device is used. This ensures that the firmware, and all sensitive information stored in memory is essentially locked down. The ability to read or write to the chip from external sources is disabled. The only way to clear this so the OnlyKey can load new firmware is to place a jumper between the two touch points of the OnlyKey shown here:
When a connection is placed between these two points it does two things, first it proves that a user is present there is no way for malware running on the connected computer to do this, second it does a mass erase of the OnlyKey. A mass erase essentially wipes everything and returns the chip to a factory default state. Once this is complete new firmware can be loaded to the Onlykey.
If you would like to read more about the flash security features of the MK20 [here] (https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf) is a document that describes in detail. If you plan to mess around with the flash security features - WARNING - Changes to the flash security settings can brick your device. We tested this feature to ensure this does not happen but any changes you make to source code are at your own risk.
##LED Definitions
Solid Light = Unlocked
No Light = Locked
Single Flash = Button Pressed
3 Flash = Wrong PIN
Continuous Flash = Exceeded PIN tries
There are 3 methods of two-factor authentication supported by Onlykey.
- Google Authenticator (TOTP)
- Universal 2nd Factor Authentication (U2F)
- Yubico One-Time Password
Google Authenticator is an application that implements TOTP security tokens from RFC 6238 in mobile apps made by Google, sometimes branded "Two-step verification" (or 2-Step Verification).
Quoting Wikipedia:
Typically, users will install the Authenticator app on their smartphone. To log in to a site or service that uses two-factor authentication, they provide user name and password to the site and run the Authenticator app which produces an additional six-digit one-time password. The user provides this to the site, the site checks it for correctness and authenticates the user.
For this to work, a set-up operation has to be performed ahead of time: the site provides a shared secret key to the user over a secure channel, to be stored in the Authenticator app. This secret key will be used for all future logins to the site.
With this kind of two-factor authentication, mere knowledge of username and password is not sufficient to break into a user's account. The attacker also needs knowledge of the shared secret key or physical access to the device running the Authenticator app. An alternative route of attack is a man-in-the-middle attack: if the computer used for the login process is compromised by a trojan, then username, password and one-time password can be captured by the trojan, which can then initiate its own login session to the site or monitor and modify the communication between user and site.
The service provider generates an 80-bit secret key for each user (whereas RFC 4226 §4 requires 128 bits and recommends 160 bits).[36] This is provided as a 16, 26 or 32 character base32 string or as a QR code.
As mentioned above the service provider generates a base32 string or a QR code. While the way you would set up the Google Authenticator app on your phone is typically to take a picture of the QR code you also have the option of displaying the base 32 string. This option is available when you are setting up an account there may be a link that says something like "Can't read QR code" that you have to click to show the base 32 key. You would then copy and paste this key into the the OnlyKey slot that you would like to use with this account.
And then press the OnlyKey button to output your 6 digit OTP into the passcode field to complete the setup. Now you can also go and set your username and password to this slot and have a complete one touch login with two-factor authentication.
Currently the Google Authenticator (TOTP) feature requires the Chrome app to be open.
OnlyKey's implementation of U2F started out with the open source implementation [here] (https://github.com/yohanes/teensy-u2f). We then reviewed the model in use by Yubikey [here] (https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/). And came up with our own implementation of key wrapping that utilizes the open source [AES-256-GCM] (https://github.com/rweather/arduinolibs) implementation we are using for encryption of local storage. When the Onlykey is first configured with a PIN a random nonce is stored that is the SHA-256 hash of random values including hardware generated noise and the capacitive touch readings from a user's skin. The private key generated for U2F key handle encryption is generated from the SHA-256 hash of the random nonce and a unique Freescale chip ID that is hardcoded onto the processor at the factory. The U2F service also provides an AppID (that is tied to the URL of the site) and during registration the SHA256 hash of the AppID is used as the Initialization Vector for the AES-GCM encryption of the key handle. This ensures that the key handle is only valid for the particular combination of device (private key) and AppID that was created during registration. By using AES-256 in Galios Counter Mode and using SHA-256 our key wrapping implementation follows NIST (SP) 800 guidelines [NIST approved key wrapping] (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf) (See Table 7: Approval Status of Block Cipher Algorithms Used for Key Wrapping and Table 9: Approval Status of Hash Functions)
For the attestation certificates we allow users to import their own certificates. We do understand that the attestation certificate in other U2F tokens is hard coded and the user is unable to change this. There is an ongoing discussion of how you can have a closed source system (or U2F token) and truly be able to trust the security of that system. This is why we are using what may be the first open source implementation of U2F that supports user import of attestation certificates.
This all being said the implementation of U2F is being released as experimental for the Beta release of OnlyKey. This has not been certified by the FIDO Alliance as an approved token. We have tested U2F authentication using OnlyKey with Google accounts.
OnlyKey's implementation of the Yubico OTP is based on the open source library provided by Yubico [here] (https://github.com/Yubico/yubico-c). The one-time passwords generated by OnlyKey have been tested to be indistinguishable from the one-time passwords generated by a Yubikey. However, some services like Yubicloud do not allow third-party devices and require a valid serial number from a Yubikey. For example, you can test your OnlyKey with the https://demo.yubico.com/ test site but you would be required to have a valid Yubikey serial number to do so.
For more information on Yubico OTP see [this] (https://www.yubico.com/products/services-software/personalization-tools/yubikey-otp/)
See https://github.com/trustcrypto/onlykey-agent
##Cryptographically Secure Random Number Generator
After much research it was concluded that Arduino and other microcontrollers such as MK20 are not ideal for generating truly random numbers. While the Arduino Reference Manual recommends using analog pins, which read random atmospheric noise to seed a PRNG, it was concluded that this method alone may not generate a cryptographically secure random number. The paper here goes into more detail - http://benedikt.sudo.is/ardrand.pdf. A true random number generator uses non-deterministic sources to produce randomness. Thus, the random number generation function in use requires user provided entropy. This is similar to how TrueCrypt used mouse movements to generate entropy during key generation. The OnlyKey RNG function uses a combination of the entropy provided from two separate analog pins (atmospheric noise) and the user’s key presses on the six capacitive touch sensors (conductivity of user’s skin, duration of key press, number of key presses, conductivity of air).
Below is an example of values read from the analog 0 pin and the touchpins values, read once per second for 3 seconds without any user provided entropy.
Analog 0 Value = 123
Touchpin 1 Value = 552
Touchpin 2 Value = 553
Touchpin 3 Value = 607
Touchpin 4 Value = 700
Touchpin 5 Value = 662
Touchpin 6 Value = 723
Analog 0 Value = 87
Touchpin 1 Value = 553
Touchpin 2 Value = 555
Touchpin 3 Value = 610
Touchpin 4 Value = 700
Touchpin 5 Value = 663
Touchpin 6 Value = 724
Analog 0 Value = 242
Touchpin 1 Value = 552
Touchpin 2 Value = 553
Touchpin 3 Value = 605
Touchpin 4 Value = 699
Touchpin 5 Value = 662
Touchpin 6 Value = 723
Without any interaction from the user there is entropy generated from analog 0 and some entropy generated from the touchpins. The touchpin’s values change slightly based on temperature, humidity, and no two pins have exactly the same sensing calibration. Below is an example of values read from the analog 0 pin and the touchpins, values read once per second for 3 seconds with user entering a three digit PIN.
Analog 0 Value = 221
Touchpin 1 Value = 551
Touchpin 2 Value = 559
Touchpin 3 Value = 6452
Touchpin 4 Value = 700
Touchpin 5 Value = 662
Touchpin 6 Value = 709
Analog 0 Value = 84
Touchpin 1 Value = 550
Touchpin 2 Value = 559
Touchpin 3 Value = 611
Touchpin 4 Value = 712
Touchpin 5 Value = 5684
Touchpin 6 Value = 729
Analog 0 Value = 130
Touchpin 1 Value = 550
Touchpin 2 Value = 553
Touchpin 3 Value = 609
Touchpin 4 Value = 6228
Touchpin 5 Value = 669
Touchpin 6 Value = 721
With user interaction, the touchpin values change significantly. Also the touchpins next to the button that was pressed change slightly just from the proximity of a user’s finger to that button. As implemented, touchpin values are read from all six capacitive touch sensors once every ~10ms and users are required to have a PIN of 7 – 10 digits. During a typical login (One button press per second), this generates approximately 56 - 80 numbers based on the conductivity of a user’s skin and 280 - 400 numbers based on the conductivity of the air around the buttons not being pressed. By performing xor and bitshift operations on these numbers we can generate a random number that is based on non-deterministic values that are completely unpredictable. Additionally, if a user enters an incorrect PIN this would generate even more entropy as this would require reentering the PIN and during use the buttons are also pressed to select sites to authenticate to which generates constantly unpredictable entropy.
We already support loading of certificates for U2F and would like to similarly allow loading of PGP certificates for encryption/decryption of email. We are looking for simple open source c/c++ implementations of PGP that could be incorporated into OnlyKey's firmware. If you are a developer that is interested in contributing to this feature or if you know of a good implementation please contact [email protected]