PasswordsFAST packaging (including feature promises)
While looking for more secure alternatives to software password managers [1] I came across the “PasswordsFAST” hardware password safe:
PasswordsFAST packaging (including feature promises)
According to its packaging, it offers easy, secure, safe and fast password management. It further uses AES-256 encryption among other claims:
PasswordsFAST packaging backside (including feature promises)
It is slightly larger than a credit card, so unfortunately won’t fit most wallets:
Size slightly larger than a credit card
The device has one quickly identified weakness with regard to brute force protection.
Timeout screen for too many incorrect password attempts
The device has a timeout when you enter the unlock password on device boot wrong too many times. However, there is no permanent lock after any amount of wrong password tries, i.e., there is no hardware enforced brute force protection. It is also possible to skip the timeout for too many wrong password entries by removing and reinserting the battery of the device.
This means the device most likely has not secure element and the encryption key is derived directly from the user entered password and security phrase giving it no additional protections besides the user entered password in case the device is lost or stolen.
The not very user friendly keypad (to say the least) makes choosing passwords that adequately protect against brute force unlikely.
The keypad is a simple foil sticker type keypad:
Foil sticker keypad
The PCB is actually screwed into the case, which is nice:
PCB is screwed in
While the front side of the PCB accommodates the keypad the backside holds the MCU and flash:
Interesting side of the PCB
nuvoTon N78E366A
The chip markings read:
nuvoTon
N78E366ALG
2209803D-152
221GEDBThis is a nuvoTon N78E366A. It is a 8051 processor and, according to the manufacturer, targeted for “Security/Alarm” (among others). This chip has, according to its datasheet “Code lock for data security”. This means its firmware is not supposed to be read easily. Therefore, I haven’t actually tried reading the firmware.
Fremont Micro Devices 24C256A
The chip markings read:
FT24C256A
7b40MEAccording to its datasheet it has a 2 wire interface. Nothing special.
All further analysis will focus on what the device stores on this flash memory only.
To analyze how the passwords are stored I setup the device with 4 different datasets as follows:
The above initialized device’s flash was dumped using the MiniPRO utilizing the open source minipro software via the following commands:
mkdir test1
cd test1
$ sudo /usr/local/bin/minipro -p FT24C256A -r flash1.dat
Found Minipro TL866CS v03.2.72
Reading Code... OK
$ sudo /usr/local/bin/minipro -p FT24C256A -r flash2.dat
Found Minipro TL866CS v03.2.72
Reading Code... OK
$ diff flash1.dat flash2.dat && echo OK
OK
MiniPRO dumping the flash contents
The encrypted username and password part of the first slot can be extracted via:
$ dd if=flash1.dat of=crypt.raw bs=1 count=96 skip=128
96+0 records in
96+0 records out
96 bytes (96 B) copied, 0.00116121 s, 82.7 kB/sAfter this the device was factory reset to input the next dataset.
The device’s flash was dumped like in Testdata 1.
The device’s flash was dumped like in Testdata 1.
The device’s flash was dumped like in Testdata 1.
Comparing Testdata 1 against Testdata 2 using binwalk yields:
Testdata 1 vs Testdata 2
From this we can see:
The data seems to be organized in 128-byte blocks. The first 128 bytes seem to be some sort of header. The next 128-byte blocks are our entries. The entries seem to follow the following layout:
struct passwordsfast_entry_t {
uint8_t tag[2]; // tag[0] = 02 for header, 01 for password entries
char description[30]; // ascii; null terminated, unless all 30 chars are used
char encrypted_username[64];
char encrypted_password[32];
};Looking at the 1st and 3rd entry of Testdata 1, which have identical username and password, we can see that the PasswordsFAST device also encrypted these username and password tuples identical:
00000080 01 15 63 63 63 63 63 63 63 63 63 63 63 63 63 63 |..cccccccccccccc|
00000090 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 |cccccccccccccccc|
000000a0 53 6a fe 82 91 5a fe dc a5 1a 28 59 3d 12 40 09 |Sj...Z....(Y=.@.|
000000b0 43 3e 3a 67 5e 10 e5 3c 16 67 5b 3b 8f 18 1d 98 |C>:g^..<.g[;....|
000000c0 3f 44 ba fe 77 2b 04 a4 e7 17 4b 62 bf fb 1a 9d |?D..w+....Kb....|
000000d0 1e ec 17 ff 4c 1b 9c a8 94 71 b6 8b 36 9e 4e 5b |....L....q..6.N[|
000000e0 b8 f5 47 44 8c 31 d6 83 ec d8 b7 4e a4 f8 e0 f6 |..GD.1.....N....|
000000f0 58 e1 8f ca ce 27 e3 79 8d e7 69 15 b9 9f 01 1a |X....'.y..i.....|vs
00000180 01 15 63 63 63 63 63 63 63 63 63 63 63 63 63 63 |..cccccccccccccc|
00000190 63 63 63 63 63 63 63 63 63 63 63 63 63 63 63 61 |ccccccccccccccca|
000001a0 53 6a fe 82 91 5a fe dc a5 1a 28 59 3d 12 40 09 |Sj...Z....(Y=.@.|
000001b0 43 3e 3a 67 5e 10 e5 3c 16 67 5b 3b 8f 18 1d 98 |C>:g^..<.g[;....|
000001c0 3f 44 ba fe 77 2b 04 a4 e7 17 4b 62 bf fb 1a 9d |?D..w+....Kb....|
000001d0 1e ec 17 ff 4c 1b 9c a8 94 71 b6 8b 36 9e 4e 5b |....L....q..6.N[|
000001e0 b8 f5 47 44 8c 31 d6 83 ec d8 b7 4e a4 f8 e0 f6 |..GD.1.....N....|
000001f0 58 e1 8f ca ce 27 e3 79 8d e7 69 15 b9 9f 01 1a |X....'.y..i.....|Which, at least according to cryptographers, is a flawed application of cryptography. Each entry should be encrypted with it’s own unique IV. However, @PasswordsFAST actually already acknowledge this problem and attribute it to hardware limitations1:
@PasswordsFAST: “There is one common key used to encrypt each record, due partly to hardware limitations. 1:41 PM - 23 Aug 2017”
Furthermore, we see that the whole encryption process is determined by the device password and the security phrase, i.e., there is no entropy generated by the device to generate a random IV. This again could be seen as a cryptographic weakness. The security phrase is basically used to seed the randomness, which is then used as the IV for encryption, or as part of the key derivation process determining the encryption key. This can be seen when comparing Testdata 1 against Testdata 4, which have the same device password but a different security phrase.
Here the task of generating randomness is given to the user. Humans are bad at generating random data. So this is not cryptographically secure.
Comparing Testdata 1 against Testdata 3:
Testdata 1 vs Testdata 3
Here we can see that changing the device password but keeping the security phrase identical will change the encryption. This means the encryption key is derived from both the device password and the security phrase. One possibility would have been for the security phrase being taken as the encryption key. But this is not the case.
However, one interesting thing to note is that only lines 0x00000040 and 0x00000050 change. If we look at an example where both the device password and the security phrase are changed also lines 0x00000020 and 0x00000030 change. One such example follows:
Comparing Testdata 1 against Testdata 4:
Testdata 1 vs Testdata 4
As indicated before, here, also lines 0x00000020 and 0x00000030 change. This would indicate that some sort of DEK (data encryption key) and possibly the IV is stored there and that the device password influences both, while the security phrase only influences one of the two.
However, without knowing the exact cryptographic implementation, it is unknown what exactly is going on.
Comparisons of the other testdata is provided here without further comments:
Comparing Testdata 2 against Testdata 3:
Testdata 2 vs Testdata 3
Comparing Testdata 2 against Testdata 4:
Testdata 2 vs Testdata 4
Comparing Testdata 3 against Testdata 4:
Testdata 3 vs Testdata 4
I then quickly tried to decrypt the data using various key and IV combinations obtained from various permutations from the raw device password and security phrase. openssl command as follows:
openssl enc -d -aes-256-cbc -nopad -K "${key_candidates}" -iv "${iv_candidates}" -in crypt.raw | hexdump -C | grep "cccccccccccccccc"None of them could decrypt the data. This means that (iff the encryption mode actually is AES-256-CBC) the AES key is actually derived from the device password and security passphrase and they are not taken as raw key material.
The actual encryption mode and key derivation is unknown. Being unable to obtain the firmware from the MCU, I did not further persue any blackbox cryptographic analysis. However, previous analysis makes me certain that, once the exact cryptographic implementation is known, the device password is exposed to brute force attacks, which are not mitigated via hardware protections.
Positiv:
Negativ:
Improvements:
Verdict:
Recommendation:
A video outlining some of this analysis is available on https://www.youtube.com/watch?v=4z7T9dt_A30
The testdata is available for download:
I also probed all the pads for any enabled interfaces.
To this end, I first soldered wires to all pads:
Soldering wires to all pads
Then probed the 6 promising looking pads for JTAG:
JTAGulator hooked up to the 6 promising pads, which turned out to be testpads for the keypad
However, these pads were hooked up to the keypad. Further investigation - why would you look into the chip’s datasheet before using the JTAGulator anyways - revealed that the device doesn’t feature JTAG and that other nuvoTon devices use SWD (Serial Wire Debug) anyway.
Also trying to interface with the RX and TX pads on the PCB, which actually are connected to the RX and TX pins on the nuvoTon N78E366A micro controller, yielded no activity.
Trying to interface with the RX and TX pads via serial
If I have missed something, or you have any other comments feel free to write me on Twitter.
[1] Wikipedia contributors, “Password manager — Wikipedia, the free encyclopedia,” 2019. [Online]. Available: https://en.wikipedia.org/wiki/Password_manager.