Consider using key wrapping - nonce generation to avoid storage on device

[alphathegeek]

Since the keys are stored on the device, and indexed by KeyHandle, it might be wise to implement the solution that the YubiKeys implement, which is essentially KeyWrapping. the device basically generates/wraps a hey with the HMAC function, so nothing besides the SecretKey is stored on the device.

This would guard against SD-Card corruption issue, while still ensuring a clonable device.

As a thought, OTP/EEPROM locations 36-43 are available for general purpose usage. This gives 256 bits to play with, good for a key?

Another idea, would be to gpg encrypt the secret key or the keystore , and use the pi-zero camera to provide a password via QR-Codes. The device only becomes unlocked once the correct password is entered. A QR code can be easily read with the camera, and could provide a good pass-phrase ala "Correct-Horse-Battery-Staple!" type, or something more/less innocuous while still being a bit more secure. This also would solve the "user presence verification" part which is currently obviously not imeplemented. The "unlocked" key could be stored in /tmp , ala ramdisk so it gets lost during power-down.

This doesn't solve all the attack vectors, but it's something I'm considering implementing, just to get some practice.

Let me know what you think, Thanks!

[Crystalix007]

Thanks for the suggestion.

Just one suggestion first. I have realised that the program starts as the root user, hence if you make the root user the only one capable of reading the file, most attack vectors are nullified immediately. For example, chmod 600 /usr/share/U2F_Priv_Keys.txt. Then, the only potential attacks are physically obtaining the micro sd-card or obtaining root on the device. Corruption is still an issue though.

I do agree that key-wrapping would be a good feature, however, to provide any greater security than a plain text file, only this program should be able to read the secret key. Using OTP/EEPROM would mean that anyone who managed to get the Pi would be able to login, whereas the current situation is that anyone with the micro sd-card would be able to log in. I don't see enough benefit, personally, to implement this myself. The only potential solution to this is the ARM TrustZone technology, which I don't particularly feel like implementing.

However, if you wish to fork and build key-wrapping yourself, successfully, I would be happy to accept the PR. I would have suggested that you use something like a password (passed to main) as the master key, as this way you could theoretically restore a U2F device. However, the keys have counters, so you would be unable to restore unless you knew the counters. I don't actually know the full details about the YuibKey's implementation, so they may have found a way around this, by storing the counter in the key itself perhaps? Otherwise, I fear that key-wrapping would not stop loss of the U2F device.

Regarding the camera idea: I don't feel like this is a great solution, as the camera alone is triple the price of a Pi Zero. The main reason for this project was to have a lower-cost solution than the existing commercial ones. Additionally, interfacing with the camera adds quite a bit more complexity. One thought I had in the past was to use the GPIO pins of the Pi with buttons such as this to implement a numpad. Then, the passcode could do key-wrapping or decrypt the keyfile.

Please don't implement a solution storing the key in /tmp however. This could be readable by any other program. Rather just keep the key in memory somewhere, as then extracting the key would require root.

Overall, feel free to implement key wrapping if you want, and if it's an improvement, I will accept a PR. Personally, I will probably add a vendor U2F command which just shuts down the Pi. That should improve the removal experience (you would just need to send that command to the U2F device rather than logging in via ssh and manually powering off). The command should be able to be sent via a browser, or at worst, a PC-side application.

[alphathegeek]

Thanks for the explanation,it looks like I need to read the specification again, I was unaware of the key counter, there are probably some more gaps in my understanding of U2F that I need to fill in first. Time to probe the code again :) The two main problems I was trying to address were corruption, which is solvable through backups, and of course "physical security" of the device/key. The security and backup problems are basically solved, if one considers this a "last resort" or backup key, which is basically the idea. Using WiFi to shutdown the pi properly for now to avoid corruption. As for the camera suggestion, I thought it would be better than buttons, as it fits in one of the smaller cases, and the QR code could provide a better password than a keypad, but your point is taken, it would increase the cost substantially for a "last resort" key, and would not do too much to increase the physical/software security of the device. Thanks again for an excellent project!

…

On Sat, Aug 10, 2019 at 5:38 AM Michael Kuc ***@***.***> wrote: Thanks for the suggestion. Just one suggestion first. I have realised that the program starts as the root user, hence if you make the root user the only one capable of reading the file, most attack vectors are nullified immediately. For example, chmod 600 /usr/share/U2F_Priv_Keys.txt. Then, the only potential attacks are physically obtaining the micro sd-card or obtaining root on the device. Corruption is still an issue though. I do agree that key-wrapping would be a good feature, however, to provide any greater security than a plain text file, only this program should be able to read the secret key. Using OTP/EEPROM would mean that anyone who managed to get the *Pi* would be able to login, whereas the current situation is that anyone with the *micro sd-card* would be able to log in. I don't see enough benefit, personally, to implement this myself. The only potential solution to this is the *ARM TrustZone* technology, which I don't particularly feel like implementing. However, if you wish to fork and build key-wrapping yourself, successfully, I would be happy to accept the PR. I would have suggested that you use something like a password (passed to main) as the master key, as this way you could theoretically restore a U2F device. However, the keys have counters, so you would be unable to restore unless you knew the counters. I don't actually know the full details about the YuibKey's implementation, so they may have found a way around this, by storing the counter in the key itself perhaps? Otherwise, I fear that key-wrapping would not stop loss of the U2F device. Regarding the camera idea: I don't feel like this is a great solution, as the camera alone is triple the price of a Pi Zero. The main reason for this project was to have a lower-cost solution than the existing commercial ones. Additionally, interfacing with the camera adds quite a bit more complexity. One thought I had in the past was to use the GPIO pins of the Pi with buttons such as this <https://coolcomponents.co.uk/products/momentary-push-button-switch-12mm-square> to implement a numpad. Then, the passcode could do key-wrapping or decrypt the keyfile. Please don't implement a solution storing the key in /tmp however. This could be readable by any other program. Rather just keep the key in memory somewhere, as then extracting the key would require root. Overall, feel free to implement key wrapping if you want, and if it's an improvement, I will accept a PR. Personally, I will probably add a vendor U2F command which just shuts down the Pi. That should improve the removal experience (you would just need to send that command to the U2F device rather than logging in via ssh and manually powering off). The command should be able to be sent via a browser, or at worst, a PC-side application. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AMHBDUFW7CKQKKTVYEE7RNTQD2D7RA5CNFSM4IKBQYP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AKAWQ#issuecomment-520134746>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMHBDUGOF3AOZ3MUQC2OANTQD2D7RANCNFSM4IKBQYPQ> .