Security: weak key material used for encrypting passwords

[rosly]

Hi,

Just by quick search I found this in zamekSecurity.unlock(): 23: key[ i ] = pinArray[ i ]; 28: aes128_cbc_enc( key, iv, data, 48 )

Means that all the key entropy came from PIN, which can be from 1 to 16 ASCII digits. Combining that with user tendency to use short PINs this solution is far from secure. Obviously, for 4 digit PIN we have 9999 key space. On my PC CPU only I would be able to crack data secured by this method up to 13 digits PIN just in one day.

Probably most of the people will use PINs far shorter than 13 digits. That's just if we considering entropy. The key should never be pure ASCII string. You need to use proper encryption scheme.

[jareklupinski]

Hi! Thanks for opening this issue; security is one of the aspects of this project I wanted to compartmentalize to easily get and implement feedback.

My intentions for this device is to allow the user to choose their own security level. For example, I choose a 4-digit PIN for my Zamek because I am sure that I would be able to change all of my passwords in less than a day if I lose my device ( using a backup I keep at home ). Other people may choose longer passwords to get extra time.

The balance between convenience and security is tough and I want to leave this issue open for discussion :)

One idea I had was to initialize the password store with a completely random 16-digit number and allow the user to edit certain digits, e.g. your randomly generated seed is 123456789abcdef, and your PIN is 4031, then the seed would be 403156789abcdef. Storing these last few digits somewhere other than a secure store is a weakness, but it needs to be nonvolatile... I assume if someone has hardware access then they can dump your payload and anything else on the device at will, so at most this should give you some extra time to change your passwords if your device gets stolen.... This probably needs input from a security expert.

[ventaquil]

In my opinion you should use key derivation function. This crypto scheme turns input into fixed-size key (for your usage it turns PIN into 128 bits length AES key).

You can use AES-KDF scheme (which is used by KeePass) or PBKDF2 (it is more flexible solution because you can choose pseudorandom function which determines security).

An additional advantage of using KDF is that this solution can stronger resist against offline attacks. You can check it on your own - just create KeePass database and in database's settings set "1 second delay" to calculate how many iterations of KDF should be set to have 1 second computation of one password on your machine.

[rosly]

Hi,

I know this is a long post but all this explanation is probably needed to clarify some misunderstandings.

Key entropy depends only on how random your key material is. It didn't mater if you use 16 digits but edit only some of them as the entropy of this solution is exactly the same as if you enter only those random digits. You probably were thinking about hash salt, which is in fact one of the ways to harden the security but against rainbow tables attack vector. Anyway to use this you need to use hashes for key material which was one elements of "proper encryption scheme" I was writing before.

But lets first clarify why your current PIN need to be long. The entropy of single ASCII digit is log2(10) = 3.322 bits (yes might seems odd that there are fraction of bits). On the other hand the iCore5 makes 55 millions of AES128 blocks encryption per second.

It means that with 4 ASCII digit key material you have ~13bit entropy for the key, which is 9999 combinations or 2^14 - 1 in terms of bit combinations that can be cracked with speed 55 millions tries per second in ~ 0.2ms Which means if you lose your device you would need to have 0.2 millisecond reaction time :) (not to much)

Ok, that was a bit of nerd joke from my side ;) So if we make our scenario more realistic. Lets assume that you will have reaction time of 6 hours (this includes time for spotting that you lost the device, like after returning home and time required to change all the passwords). If we also assume that the attacker would have 10 machines with 12 cores (which is not big number as you can buy 6h of computing time for such cluster under 10$ and as you already noted in your code you only need to decrypt first block of 16 bytes to reject garbage non ASCII output), that's 55M/s 12 10 = 6.6 billions blocks per second. And that's not even close to what some guys have for serious cracking on GPU farms or zombie botnet.

So: 6.610^9 3600 6h = 1.425610^14 blocks decrypted during 6h window log2(1.4256*10^14) = 47 bits entropy scanned during the 6h window 47/3.322 -> ~14 ASCII digit PIN or 47/5.12 -> ~9 ASCII small letters and digits PIN

As you see those are rather long PINs even if we assume that there is any sense in the computations I just made, since nobody calculate the amount of entropy needed to secure assets from 6h long attack (silly method) ;)

As the solution I propose:

• as I assume the power of HW device is that password is entered by different channel than PC (which can be intercepted) change the password input method for convenient way of providing long passwords (like touch screen)
• use hashing with salt and many rounds for key derivation method (like couple of thousands) to slow down the cracking process (ventaquil already proposed this while I was composing my reply ;))

[jareklupinski]

Thank you for the detailed explanation @rosly, I have not been keeping up with how fast keys can be cracked on modern hardware, to me it makes sense to use both methods, and you are correct the current hardware limits the ease of inputting a long enough key.

I am thinking about a redesign of the way keys are generated and input by the user ( using hardware because I am more comfortable with hardware haha ) and need to do some more research on the easiest way for people to accurately replay a long enough key that will be useful to feed into @ventaquil's proposal :)

[SatanRage]

what about a biometric fingerprint sensor, how hard can be to implement? i see that a lot of phone implement already that like Fingerprint-->hash from biometric data-->decrypt at example there is a fingerprint module : https://gdfingerprint.com/product/fingerprint-sensor-module-s22/