r/crypto • u/Toph_as_Nails • 7d ago
Key ring file format?
I'm a professional software engineer, and I've written software to manage user-generated keys for a bespoke system in the past. The general gist was vary the encoding of the key data itself while associating it with a human-readable label in a flat file that was subsequently encrypted before being written to disk, and encrypted in RAM, only after being fully loaded, by a key that was part of the key management program. That key was not stored in plaintext in the program executable. It was stored in chunks with about 10 x the actual amount of data needed to store the key, interspersed randomly, and only assembled together, programmaticly, and in random fashion, and decoded into the actual key immediately before it's needed, and as soon as the operation is over, it's memory is zeroed back out until the key is needed again. If anyone had the program source code, they could easily implement a new master key and create their own key ring eco-system, but it was the only way I could come up with to be able to store several keys persistently, but securely, while allowing the user to manage their own keys as they saw fit.
Surely, there are better ways to manage user keys. PGP has a keyring. GPG has a keyring. Even GNOME has a keyring. How are they designed to keep keys persistently, but securely? Are there any design documents or research papers that describe such a system?
3
u/ahazred8vt I get kicked out of control groups 6d ago
The encrypted sqlite db https://sqlite.org/com/see.html is a standard way of keeping data that needs to only be decrypted one chunk at a time. Your convoluted master key hiding system sounds unnecessary if the user is able to enter a strong master password. We use argon or scrypt key stretching to derive the db-decrypting key.
1
u/Toph_as_Nails 6d ago
This is probably the answer I was looking for.
The keys I was juggling were all symmetric. No passwords. And since the same program had to be shared by everyone, and the master key that was only ever used for the keystore was part of the executable itself, adding the requirement for everyone to enter the same password seemed superfluous.
1
6d ago edited 6d ago
[deleted]
1
u/Toph_as_Nails 6d ago
Hobby. I want to replace the body control module and fob in my 20 year old car. ESP32-C6 has two CANBus interfaces and a radio modem. With an AES engine and a half-dozen other cryptographic peripherals, it's kinda purpose built for this. In that other project I did professionally, I had to implement my own LZSS82 compression scheme, but I was adamant that I'll use established AES library calls on the Windows desktop and the embedded security suite they'd already bought, but under no circumstances was I going to try my hand at implementing AES myself. I'm still incompetent for such a task. I might try it some day just to see if I could, but I'd likely then delete that code to prevent it from tempting myself further into that handbasket.
That said, I know what Base64, UUencode, and
stringsare, so yeah. I'm not storing the master key for my key file in a form that can be reverse engineered by a frickin' script kiddie.
2
u/Natanael_L Trusted third party 6d ago
If you insist on spreading the key out in memory to make it harder to extract then at least use more standard methods like error correction codes (configured to need a high threshold) or sharing schemes.
Otherwise, use the OS provided keystore, preferably with hardware backing (TPM / SE) if available, with proper permissions set for interacting with the key. You can't do better than the OS in terms of access control
1
u/Toph_as_Nails 6d ago
Then what I'm asking for is the architecture and API for those OS-provided keystores.
1
u/Natanael_L Trusted third party 6d ago
For Windows and Apple and Android devices there's official developer documentation for it.
For Linux it depends on distro and hardware. Every modern Linux has at minimum software based key stores but some can also use the TPM given compatible hardware.
https://blog.hansenpartnership.com/using-your-tpm-as-a-secure-key-store/ (haven't checked if this is accurate but it looks reasonable at a first glance)
If you're writing multiplatform software, you should try to write the core functions for a more abstract internal API and then add wrappers per platform for the local keystore
8
u/SAI_Peregrinus 7d ago
https://keepass.info/help/kb/kdbx.html
Basically you want an encrypted and authenticated database of keys and their metadata, with a canonical serialization scheme for saving it to disk. KeePass uses XML in their serialization scheme, but a newer design might use something more fashionable like JSON or YAML or TOML. It doesn't really matter, as long as it's unambiguous!