LED Definitions (OnlyKey Color)
- Steady Green Light = Unlocked
- No Light = Locked
- Single Yellow Flash = Button Pressed for PIN entry
- 3 Red Flashes = Wrong PIN
- Continuous Red Flashes = Exceeded PIN tries
- Continuous Green Flashes = Backup and restore is complete.
- Blue Fade in and Fade out = U2F request
- Purple Fade in and Fade out - Private key signing request (SSH or PGP)
- Turquoise Fade in and Fade out - Private key decryption request
- Red Fade in and Fade out - Device is in config mode
LED Definitions (Original OnlyKey)
- Steady Light = Unlocked
- No Light = Locked
- Single Flash = Button Pressed
- 3 Flash = Wrong PIN
Continuous Flash = Exceeded PIN tries Or if you just did a backup and restore, the restore is complete.
- Fade in and Fade out = U2F, SSH, or private key operation request Or if you have placed your device into config mode
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 up 12 unique accounts using strong 56 character passwords along with the usernames and two-factor authentication. This way whenever you need to log in you just detach the OnlyKey from your 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.
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 (TOTP)
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).
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). 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.
Universal 2nd Factor Authentication (U2F)
OnlyKey’s implementation of U2F started out with the open source implementation here. We then reviewed the model in use by Yubikey® here. And came up with our own implementation of key wrapping that utilizes the open source AES-256-GCM 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 (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 and private key 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. A closed source product is not verifiable, and requires you to trust that the vendor was not compelled to put a backdoor into the product. This is why we are using what may be the first open source implementation of U2F that supports user import of attestation certificates.
What is attestation and why would I load a custom certificate and key?
Short Answer - A custom certificate and key is generally not needed. Keeping the default attestation certificate and key is good for privacy as there is no personally identifiable information in the default key. However, there are some use cases like if an organization wants to load custom certificates and keys to devices so that employees only use the company issued device.
Attestation is basically U2F’s way of attesting that a token is from a certain vendor. For example, if you were to use a Yubikey, the website would know that you were using a Yubikey to authenticate instead of some other vendor’s device as shown below:
This is good in some ways as website’s may be able to only permit certain vendor’s devices that they trust. But there are two big problems here:
1) This also can be used to track users and has some serious privacy implications. As shown in the output from U2F authentication you can see that a unique serial number is visible.
It is unclear if manufactures generally use a unique serial number for each device or a batch of devices. Either way there are many cases where this may permit identification and tracking of the user.
In the case of unique serial numbers the website knows exactly which device was used to authenticate. Knowing what device was used in one step away from knowing what person is accessing the website. And along with this at what time they accessed it, from what location, and what they accessed. If the website were to receive a national security letter they would then have to turn over this information on all of their users. This metadata provides a way to track user’s activity and identity with precision.
i.e. Bob uses his device to authenticate to Google and to Facebook. Agency X knows that serial number ‘123456’ device is used to authenticate to Google and Facebook. Agency X knows that this Facebook account belongs to Bob because he has a profile picture of himself, now they know that the Google account also belongs to Bob along with every other account that has a device with serial number ‘123456’ assigned.
OnlyKey addresses this issue by using a generic certificate. The serial number of the default attestation certificate on OnlyKey is ‘1’, this is the same across all OnlyKey devices and to even further obfuscate the identity of the user this same certificate is used by another device (software simulated U2F). So this way there is no way to prove that you are even using an OnlyKey. This makes it so that U2F can be used without compromising privacy.
2) You can never have an open source U2F device with a “trusted” attestation key/certificate
In order to be open source it must be possible for a user to change the source (firmware) running on their device. Otherwise, there is no way of knowing what firmware is running on their device or if the vendor was compelled to put a backdoor into the device. But if you allow a user to change the source on their device now you have just invalidated the attestation that this device is a trusted device from a certain vendor. Open source U2F and attestation are essentially incompatible.
At this point this is not much of an issue as websites allow all U2F token’s and do not enforce the attestation. If this were to occur, then open source U2F tokens would no longer work. As many user’s do not trust closed source systems for privacy reasons, if this were to occur there may be a need for a new open source friendly fork of U2F to be developed, or use an alternative form of 2FA.
This all being said the implementation of U2F has not been certified by the FIDO Alliance as an approved token.
Yubico® One-Time Password
OnlyKey’s implementation of the Yubico® OTP is based on the open source library provided by Yubico® here. 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
The keys feature allows you to use OnlyKey to store private keys that can be used for SSH authentication, OpenPGP Signing, OpenPGP Decryption, and secure OnlyKey backup. You can store 32 ECC private keys and 4 RSA private keys. Each key also has a label assigned to it so just like with slots, an identifier can be assigned to each key.
Under the hood -
- Up to 32 ECC keys are supported of type curve25519, P256 (NIST), and secp256k1 (Used for Bitcoin)
- Up to 4 RSA keys are supported with key sizes 1024, 2048, 3072, and 4096 bit keys.
Keys are loaded using the OnlyKey Chrome App. For a demonstration see https://vimeo.com/210800252
SSH Authentication - Currently only ECC keys are supported for SSH authentication. Using the OnlyKey agent ssh authentication can be accomplished by storing a key on the OnlyKey and setting it as an authentication key. The benefit this provides is that your private key is never exposed on a computer where it can be compromised by hacker.
Email/File Signing (OpenPGP)
Using the OnlyKey PGP Message Tool, the OnlyKey supports signing of email and files using OpenPGP (PGP/GPG compatible). This feature is currently released as proof of concept, additional work is needed to properly generate signatures that can be validated.
Coming soon - Email/File/Chat Signing in browser using Keybase.
Email/File Decryption (OpenPGP)
Using the OnlyKey PGP Message Tool, the OnlyKey supports decryption of email and files using OpenPGP (PGP/GPG compatible). This feature is currently released as experimental, to try it out we recommend encrypting emails with Mailvelope (Using RSA 4096 Key) and decrypting with the OnlyKey PGP Messege Tool. The benefit this provides is that your private key is never exposed on a computer where it can be compromised by hacker.
Coming soon - Email/File/Chat Decryption in browser using Keybase.
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 setup 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.
Plausible Deniability (International Travel Edition and Standard Edition of Firmware)
Wouldn’t it be nice to be able to be able to travel to a country where encryption is illegal or to a country where it is against the law to refuse to give up your password to authorities and be able to comply without actually giving any access to your accounts? That is what the plausible deniability feature is all about. OnlyKey allows the use of a hidden profile and a fake profile (Plausible Deniability Mode) that essentially provides a cover story. If compelled to do so a fake profile can be activated by entering a plausible deniability PIN code and the goal of this feature is that there is no proof that the hidden profile even exists. In fact since the international travel edition of the OnlyKey ships without the plausible deniability feature there is no way to know if you are using an OnlyKey with the international travel edition firmware or the Standard Edition firmware in plausible deniability mode. When the Standard Edition OnlyKey is in plausible deniability mode it is essentially indistinguishable from an International version OnlyKey.
Now that you understand the basics of how the plausible deniability feature works the reason for having two versions of firmware becomes more clear. The genius behind the plausible deniability feature that makes it possible is a three part solution.
Part 1. We ship two versions of the OnlyKey, an international travel edition and a standard edition. We can ship the international travel edition anywhere in the world because this version is basically just a password manager that does not utilize encryption (No U.S. export restrictions). The Standard Edition on the other hand does utilize encryption and has the plausible deniability feature that when activated makes the OnlyKey appear to be running the international travel edition firmware.
Part 2. Both versions utilize physical flash security to essentially lock the information stored on the devices so there is no way to know what version a device has loaded. We have taken great care to ensure that the plausible deniability mode on the Standard Edition Version acts exactly the same as the International Travel Edition.
Part 3. We make it easy for user’s to load whatever version of the firmware they want. International customers can easily load the Standard Edition and vice versa. Even we have no way of knowing what version of firmware a device has loaded.
Anyone can view the open source firmware here and verify that this is the case. Since there are devices that ship without the ability to perform encryption it is plausible that your OnlyKey is one of these, just a basic password manager. There is not a way of knowing that there is another hidden profile that is only activated if you know the secret PIN. Best of all, changing the version of firmware on your device is easily accomplished as the OnlyKey is field upgradable. There is a section in the user’s guide here that provides instructions on flashing whichever Onlykey firmware you want.
So now you can see how a user if compelled to do so could say ‘‘I just have a basic password manager, here is my PIN code’’ and it would be completely plausible that they do in fact just have a basic password manager. To be even more plausible the user should set up actual accounts with real credentials which work to log into websites.
Are these the user’s real accounts or are really just dummy accounts and there is another hidden profile? There is not a way of knowing.
Alternatively, if you don’t need the second profile for plausible deniability you can just use it as a second profile to store additional accounts, such as a personal profile and keep your work accounts in the primary profile.
For more information on encryption and international travel see https://www.princeton.edu/itsecurity/encryption/encryption-and-internatio/
Q - When should I use the plausible deniability PIN?
A - Whenever you wish for your OnlyKey to appear to be a simple password manager that does not utilize encryption. Form more information on Plausible Deniability encryption see https://en.wikipedia.org/wiki/Deniable_encryption
Q - When should I not use the plausible deniability PIN?
A - Plausible deniability is only good if you are in a country where your worst case scenario is that you will be fined for using encryption. If someone is holding a gun to your head or there is risk of torture plausible deniability is pretty much useless. For more information on why see this https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis.
When it comes to hardware security there are terms such as tamper resistant, tamper proof, and secure element. 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. This standard defines 4 security levels.
A simplified explanation of these levels can be found on wikipedia (Notice that even the highest security level is not tamper proof)
While we do not plan on pursuing FIPS certification we can attest that OnlyKey meets many of the requirements of FIPS certification including using a FIPS approved algorithm (FIPS 140-2 Level 1 - AES-256 is an approved algorithm). The coating of the OnlyKey would be difficult to remove and not easily dissolvable with chemicals like plastic coatings. In our testing chemical removal of the coating results in noticeable damage to the OnlyKey that results in evidence that it was tampered with (FIPS 140-2 Level 2). In the same way attempts to manually delaminate the potting compound in our testing will also delaminate electronic components rendering the device inoperable and creates visible damage to the silkscreen/soldermask layers.
In addition to this, we enable the Kinetis flash security 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 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.
This secondary feature has been added to provide additional protection against the following scenario:
Bob leaves his OnlyKey unlocked and plugged into his computer and walks away, Alice walks up and loads her key onto Bob’s OnlyKey and sets this as the backup key and then uses this to create a backup. Alice now has the encrypted contents of Bob’s OnlyKey and knows the key.
While Bob should not have left his device unlocked and unattended we still want to prevent this scenario so first a device must be in config mode to load keys or to restore from backup. To put a device in config mode hold the #6 button down for 5 seconds on an unlocked OnlyKey, then re-enter the PIN. This ensures that only someone who knows the PIN can select the private key used to create a backup.
For a demonstration of backup feature see https://vimeo.com/210800252
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 re-entering the PIN and during use the buttons are also pressed to select sites to authenticate to which generates constantly unpredictable entropy.