I am looking to see if anyone has made a password keeper where you can create passwords that the flipper will input on a computer. We service different customers access control systems and some sites have their own passwords, its hard to remember them all. It would be nice to make a database of passwords to where i can just plug the flipper into the computer, select the password section, and click on the site to enter the password for that system.
You can do it with BADUSB scripts.
BUT all the passwords will be stored at flashcard in plaintext and will be compromised if your device will be lost/stolen.
Perfect! I actually just created some files using alt codes instead of plain text so even if someone finds the file they would have to know what alt codes were. Not much security but better than nothing.
The U2F app uses some kind of internal keys. Perhaps that can be used in some way.
Unfortunately not, there is no user accessable secure enclave/TPM on the flippers. The radio core has an SE (built from Trustzone), but you can only really program that under contract and NDA from the manufacturer. Without being able to program the radio core, even if you generated and used keys from the SE (this model does support some user-mode keys), you would have to configure the SE to nuke the keys on every firmware update (otherwise, I could load a malicious firmware that just orders the SE to decrypt everything). TPM/SE emulation just needs to happen entirely in the trusted zone/radio core (which I am unsure is even possible on these models). This means the whole u2f app, or pgpcard app, and so on.
If we take it a step further, and require firmware updates to be signed by a key loaded into this trusted zone, we could extend the trust to the whole firmware, leave the u2f app where it is and could seal all key material on the flipper (sub ghz, RFID, etc), and actually have it be quite secure.
1 Like
I don’t think any of us want signed firmware. That would destroy a lot of the fun.
Just like everything else, it depends on how it’s used: if user keys can be added to the root trust store (like all actual TPMs in the wild), it just means adding a step to sign the binary to your makefile. It would also mean that no one else could load their hacked firmware onto my flipper. (You can also do pretty cool things with the TPM in your machine, like running a virtual pgpcard.)
The scary part is if the ability to load user keys goes away, especially on “general purpose” computers. People are right to be afraid of that, but what we have now is actually pretty great.
I’m not concerned that the flipper team would lock us out of adding user keys.
1 Like
Wouldn’t we need to build the firmware ourselves then? I’m not afraid of them closing us off either considering how much is open source. That would be contrary to what they have been doing so far.
The way it works in general purpose x86 computers with a TPM right now is that the motherboard manufacturers preload a key controlled by Microsoft who then sign keys for the various popular Linux kernels (now that big blue owns red hat, I’m really hoping they’ll be able to throw their weight around and get a key directly included in TPMs in the future). Furthermore, you can add your own keys to let it run code you complied yourself, or even disable the preloaded keys to only let it run code you’ve signed yourself.
The flipper could be set up the same way: run firmware signed by the flipper team and optionally, if the user so chooses, code they compile themselves.
(To be clear, this would be by no means an easy matter for the flipper team to implement, and might even require another chip depending on just which parts of Trustzone the CPU manufacturer allows the flipper team access to.)
The flipper is great at gathering secrets, it would be amazing if it had mechanisms to keep it’s own. I’d love to be able to carry around my (secure) keys in it. One of the many things I admin is a door-entry system, and I’d love to be able to justify authorizing it to be one of my entry fobs—I’d write the NFC PIV app myself—there just literally isn’t a secure way to do it right now. Right now, the flipper just isn’t a good place for any of your own secrets (like a password manager per the topic).
1 Like
AFAIK (according to documentation), it is.
1 Like
Awesome if true! It’s been many months since I looked into writing a pgpcard applet. Do you have a link?
1 Like
I’ll be watching this space. My understanding is the U2F app is safe and secure. Is that correct? It’s always nice to have an extra security token.
No definitely not secure yet, it’s close to being viable tho: OpenPGP Card Applet
Basically, it does seal it to the user SE keys, but without some form of firmware signing, all I would have to do is load a malicious firmware to your flipper and tell it to spit out the plaintext of your u2f key (I suppose it would be hilarious if you have one flipper do this to another, but, I’d much rather have my flipper be an acceptable place for certain keys (you would still want to have any sensitive keys on dedicated hardware, like a yubikey, or a HID Crescendo card)).
1 Like
I’m referring to flipperzero-firmware/scripts/ReadMe.md:
Never flash FUS or you will loose your job, girlfriend and keys in secure enclave.
But remember:
- Putting your code for PGP inside means flashing and losing built-in keys such as one encrypting KeeLoq things - yes, you can abuse it to get everything before flashing, but that’s tricky - mine attempts wasn’t successful, and you will be cut off updates.
- FUS is part of Core2 which, as already mentioned, deals with proprietary blackbox. So good luck with modifying code.
- If you want a YubiKey, get a YubiKey. Or NitroKey. Or something else originally designed for security.
The FUS is the Firmware Update Service, at a lower level than the actual firmware itself. If we could update that without nuking the keys, we could make the radio core do anything: it’s what’s in charge of making sure code on the radio core is signed by someone authorized by the manufacturer (amongst other things)
https://wiki.stmicroelectronics.cn/stm32mcu/wiki/Connectivity:STM32WB_FUS
You can test yourself that this isn’t case: create a u2f key, update your flipper’s firmware, and it still works.
I kinda agree with you in that I don’t personally see the use for a u2f key on anything but the most secure dedicated hardware you can get your hands on: it’s very much so meant to be a dumbed down system that people can actually use, there’s no notion of key strength or any way to do key revokation without just going to every site an manually removing it.
Pgp and PIV are different, you can have keys for different purposes and have heiarchical trust relations between the keys, you can sign a single statement that a key has been compromised and have it no longer trusted across your whole system. Monkeysphere is a really cool project built out of these properties. I certainly wouldn’t put any [C] keys on the flipper, but [SA] subkeys would be really nice if I can become convinced of the flipper’s security.
Furthermore, having this functionality would make the flipper a much better place to keep whatever insecure keys you have to use (hotel room keys, garage door openers, etc) basically limiting the attack surface to when you choose to transmit and actual vulnerabilities found in the flippers firmware
I can’t make too much sense from your message, but the points I’m ready to reply:
You can test yourself that this isn’t case: create a u2f key, update your flipper’s firmware, and it still works.
That’s exactly the difference between FUS and core2. I believe “Secure Enclave” and “FUS” are the same or at least share protection, so my idea is the same - code capable of accessing secure contents can only be changed simultaneously with wiping the secrets.
I kinda agree with you in that I don’t personally see the use for a u2f key on anything but the most secure dedicated hardware
Another reminder - security functions are not the main thing in Flipper, but only a bonus.
Pgp and PIV … Monkeysphere
That’s forum about Flipper, not about crypto and security. Our discussion is interesting, but largely offtopic.
but [SA] subkeys would be really nice
I wouldn’t do it. First, someone who compromised a Flipper - even the outer layer - can use a BadUSB to own your system. And someone who haven’t, cannot defeat even current system. Second, with [SA] an attacker can sign a transition statement - and if you later revoke the key, it only adds up to the mess.
Furthermore, having this functionality would make the flipper a much better place
This part was asked from devs. They ruled out FDE for SD card, but (were?) considering encrypting individual files with PIN+SE key.
I think I see where we are talking past eachother here: the FUS and SE are different things, but related (and both need to be in place for either to be useful).
The SE has both “user keys” and system keys. The idea would be to configure the FUS wipe away the user keys on every firmware update. The FUS itself uses the system keys, so would not be affected. To your comments, obviously, I can’t write this myself as it requires signed code, hence why I’m talking about/explaining it to the community to see how interested others are, rather than just slapping it together myself (it’s a really quick and ugly hack).
That being said, actually signed firmware would be much better. I’d rather not have to regenerate my keys after every update
Dude… The rest of us are talking about things we want to be able to do with our flippers, just because you aren’t personally interested in using your flipper this way doesn’t mean it’s off topic.
The flipper is largely about gathering key material, protecting key material is implicit in the problematic. Just look at all the topics across this the forum that basically boil down to people wanting to protect their own key material on the flipper (this one started with a password list). A tonne of people (obviously myself included) want to be able to do this. The hardware is there (tho if there is a hardware revision, I’d love a discrete, capable, SE chip).
I have different security requirements than you. For example, I use Cherry’s secure keyboards and configure my kernel to only accept signed input (and find it insane that cherry is the only one who makes these).
I also have about 5 [S] keys and 6 [A] keys (linked to different [C] keys, least privilege and all (all just for work)), about half of them I’d be comfortable to load onto the flipper if it had appropriate mechanisms in place to protect them (for example, one is just protected by a software password right now, the flipper’s current state is even worse than that). Different people have different use cases.
Furthermore, I truly don’t see the point you are trying to make? If you get pwned then you are pwned so might as well not even try to make anything secure? A badusb hidden in a USB cable could own your system too. It couldn’t exfiltrate key data, however. The same would be true of a YubiKey. Requiring signed firmware would also be the first step in preventing malicious applications from being loaded in the first place.
I think you are mixing up [C] and [S] or [A], unless by “transition statement” you mean something like an email saying “this is totally my new key guys!!!”. The CA I run would never accept such statements, nor would any I’ve even heard of (and I’ve worked with some nasty/really stupid ones).
That would be awesome! Do you have a link? Obviously, the same problem with a malicious firmware just emitting the plain text applies, which brings us back to signed firmware. But this would definitely be a step in the right direction
My interest in using the Flipper as a key was really about the convenience of a single device. I’ll stick to my Yubikey’s then because it’s not worth the risk of a cloned key walking around.
Definitely the right decision for now
(tho if there is a hardware revision, I’d love a discrete, capable, SE chip).
Revision is planned, so maybe…
It couldn’t exfiltrate key data, however.
Keystroke reflection.
unless by “transition statement” you mean something like an email saying “this is totally my new key guys!!!”
Exactly. People do it, I can dig examples. And some will believe.
Do you have a link?
Not sure. Try looking through issues on GitHub.
1 Like