Security

The FinalKey is designed so that any action which either changes or outputs data requires the device to be unlocked and the user to press the button on the device. The means that, in order to compromise a FinalKey a malicious person needs to have physical access to the device, and to be able to know the master-password.

• Security Overview
• Security
• Physical access
• Backup files
• Third party analysis
• Key derivation function
• Encrypted key being used as mac
• My comments
• Compromised systems
• Man in the middle attacks
• Extra Paranoid Master Password
• Hacking Challenge
• The prize
• The challenge
• The rules
• Answers to asenine questions

Physical access

Because every action which may alter or reveal data requires the button to be pressed, an attacker with access to the computer to which the FinalKey is attached, cannot get anything out of it.
With the exception of the theoretical attacks mentioned below.

Backup files

When a back is taken of a FinalKey, the contents of the storage is dumped into a file. This file contain only the greeting-banner in clear-text, the rest of the file is encrypted.
However, the efficiency of encryption depends on the cipher, (the master passowrd) used to encrypt it, therefore, a very strong master-password should always be used, and backup files should never be stored on a computer, but instead kept on a safely stored offline media, such as a USB flash drive or floppy disc (if you're old-school).

Third party analysis

A project evaluating the security and suggesting solutions to found issues has been defended at Aarhus University and the cryptography group awarded the project top grade, meaning that it carries a good amount of credibility.

The author has graciously contacted me, and given me permission to publish it here.

The project is an interesting read to those who consider adopting the FinalKey, those who may want to create an even more secure solution, and those who are interested in the finer details of security.

The document can be downloaded here: FinalKey_Project_Peer_AU.pdf (©2015 Peer Bech Hansen)

I do not dismiss the validity of any claims made within, and I have submitted to amending the (in my opinion) two most severe issues:

• Inadequate key derivation function
• The encrypted key being used as mac

A firmware which amends these issues are available in the CryptoCorrect branch.

This version is not compatible with the GUI, does not have macro functions and does not support scrambling the master password. It will be possible to order FinalKeys with the extra paranoid firmware. The new firmware is not compatible with existing FinalKey data, and any existing data will be overwritten.

Key derivation function

A key derivation function serves two purposes:

• To create a high-entropy key suitable for encryption, from a low-entropy user-provided text password
• To slow down/increase cost, of brute-force attacks relying on attempting all combinations of a user password

Creating a high-entropy key was not truly an issue in the original implementation, but it was simplistic, I have solved this completely by hashing the password with a 64 bit truly random salt, several hundred times.

Computational expense is relative to the hardware on which the algorithm is run. I argue that it is impossible to implement a function on a 16 mhz 8 bit chip, which is expensive on a multi-gigahertz 64 bit PC, GPU, FPGA or ASIC system, while still being able to complete in any acceptable time on the micro. I do not consider this a serious problem, as the FinalKey allows 32 character passwords, and if you are concerned with security in brute-force scenarios, you should use all 32 characters.

Encrypted key being used as mac

A MAC in the context of FinalKey is a construct which is used to determine if the key can be unlocked with the provided password. There is a theoretical weakness in AES when encrypting the encrypting key. This is exactly what I did in FinalKey, and that is a flat out mistake on my part, as I was not aware of this weakness. I have fully fixed this, by generating a truly random 32 bit number which is then used for MAC.

My comments

I'd like to point out that the two severe issues describe specific situations, where an attacker has obtained a FinalKey, or stolen a backup file (which should be kept offline anyway).

There is a lot of focus on "expensive" hashing algorithms, it is my observation, that these algorithms protect against bruteforce of short passwords (You can bruteforce any 8 letter password in a few seconds without an expensive algorithm), since it is effectively impossible to create an expensive algorithm on a 16 mhz chip, the solution to this problem is to use a long and strong password. Such as one using all 32 characters. at which point, the search space becomes 92^32 (693 novemdecillion), which should require considerable computational power, with or a super expensive hashing algorithm.

As noted above, I fully acknowledge the issues, and I have done my best to amend them.

I will not fix secure USB communication (and protection against key-loggers), it will not prevent the memory of the receiving application from being read, thereby sniffing logins in the actual text-field memory. Any logins used in a compromised session should be considered leaked, that's the world for any authentication that does not use out-of-band two-factor authentication, this can be obscured but not dismissed.

Compared to other one-factor systems, the FinalKey can, as far as I understand, still be considered among the most secure.

Compromised systems

Using the FinalKey on a known compromised system is of course not encouraged, don't use compromised systems, if you suspect you have a virus, it's time to re-install, if you suspect a public system may use a keylogger or other software, destroy the system, or at least refrain from using it.

That being said, in the case where a FinalKey is connected to a compromised system, the only information that can be obtained is the accounts being used. Obviously, if you log-in to facebook on a PC with some sort of survailence software, your facebook-credentials are going to be recorded, and that is of course also true for your FinalKey.

Man in the middle attacks

A man in the middle attack would be a scenario where someone has installed software on your machine which can intercept and change the information between you and the FinalKey, for example, modify your keypresses, so that you are not entering the account-number you think you are.

For example, you want to log into "WebSiteA", account-number 00, however, the software changes this to account-number 0f (home-banking, or other important site).
The FinalKey will show which action is going to be done and on which account, so if you pay attention you will notice this right away, it will either mean that you pressed the wrong numbers, or that someone actually tried to trick you to enter a different account-number.
In case you are certain that you entered the correct number, the system can be assumed compromised and you should change the master-password on your FinalKey, and remove any backup-files you have, as they are encrypted with that same number.

Extra Paranoid Master Password

Aka Scramble.
Available since commit commit ad736b9ad1

Pressing the button during text-entry will scramble all following characters according to the amount of button-presses and where in the string they occur, please refer to the Extra paranoid master password section of the cli-manual for more information on how to use it, this is the technical description of its implementation.

• When text-entry begins, the scramble-counter [SC] is set to 0, meaning scramble is disabled.
• When the button is pressed, the SC is incremented and the pseudo-random-number-generator (PRNG) seed is set to the new SC value.
• If the SC is not 0, the LED will turn on and backspace will no longer erase the last character, it will erase the entire string, output << and change to a fresh line.
• When the SC is not 0, a freshly input chracter is XOR with a fresh value from the PRNG.

For example, pressing the button once, then pressing A 10 times will result in 10 different values, none of which will be a.

Let us examine what happens in the case of {4}onePass{2}word{1}!

I am not aware of the complexity of brute-forcing the potential button presses of a known password, it may not be very difficult, and this feature should not encourage irresponsible behavior concerning the master-password.
My unqualified guess, is that brute-forcing the button-press part of a known would involve the same algorithm as The FinalKey uses, through the known password with a low number of mutations on each character.
For example, assuming that the button was never pressed more than 10 times at any one point, I believe that the number of mutations needed to cover all possibilities would be length^10.
If anyone has comments to this feature, I'd be happy to hear them!

Hacking Challenge

I made the firmware, I'm not an expert in cryptography, and I have invested a large amount of time in trying to break it, and thinking about how to break it and I have failed. I am now convinced that it falls well outside my abilities. However, this being the internet, a lot of people out there are a lot smarter than I, and therefore, I'd like to present you with a little challenge.

The prize

A Final Key, assembled, white or black, your choice, posted to you for free. The prize goes to the first who succeed, second place is just the first loser.

The challenge

You have the source code for the firmware (github) and a backup file (finaldump.bin), which is a backup taken using the FinalKey backup program, it is the raw dump of the eeprom + crc8 for every 32 bytes.

This is the exact data you would get if you gained access to a backup from a user who did not follow my advice and store their backed-up files on off-line media (like another final-key or a removable storage device).

If you remove every 33th byte (copy 32 bytes, skip the next, rinse, repeat), you have exactly the raw data that you'd get if you stole a Final Key and dumped the EEPROM via hacked firmware or over I2C.

64000/32 + 64000 = 66000 = bytes in finaldump.bin

You're basically getting everything you could ever hope for, this is the most ideal situation any attacker could possibly wish for, except for short of the encryption password, but that would be boring, right?

Bonus hint: There are at least two valid email addresses in the file.

The rules

You do not have to provide the encryption password, any way you get data out of this is acceptable but:
You must provide a clear-text dump of all stored account names, user-names and passwords on this key.

Furthermore, because this is for learning purposes, you must document your attack, for example on a website, in a pdf file or on a blog post, your documentation must provide detailed description of the attack and include any code you wrote to pull it off and names of any existing tools used. - This article must be licensed in such a way that it can be publicly released, as it will no doubt provide for very interesting reading.

Contact information is embedded in the file.

This page will be updated as soon as I receive the first succeeded break, the winning article will be posted or linked to from this page.

Too much work for too small a prize ?
Certainly, if you do not count how awesome it'd be to get a free piece of hardware! It's even got something 3D printed, and LEDs, hackers love LEDs! it also shows the world, not only how bad I am, but also (more importantly) how awesome you are!

Good Luck and Have Fun.

finaldump.bin (md5: 765e212fdd9a79debb84af0795eedede)

As of 2015-04-28 the dump was downloaded 6104 times.

Answers to asenine questions

and dumb assumptions

The hotglue won't stop anyone from tampering with the device!
No, and it wasen't intended to, nobody ever said it was.
The hotglue is there to protect the electronics against bumps/scratches/dirt/moisture.

Anyone with a keylogger can get the passwords!
Yes. This is true for all solutions. (See scramble).
However, the keylogger will only obtain the passwords actually entered by the FinalKey (and yourself), and even if someone has your master-password, they can't do much with it without your FinalKey.
Software-based managers, which may not use the input-subsystem, are still vunerable to keyloggers, as their master-password will be sniffed, and since they store the password-database locally, they are vunerable to be completely decrypted.
2 factor auth are still vunerable to MITM attacks carried out on a compromised machine.
In short: If the system is compromised, it's vunerable, go away.