Security Squid

Security Squid is the name for a hardware-based password manager inspired by the mooltipass hardware security manager, but with a set of different design goals which diverged from the final mooltipass products. It essentially imagines the same core functionality but with a very different set of goals regarding some aspects of security and all of the UX.

Brainstorming

In no particular order, here is a set of things which are important to security squid:

On Passwords

• Passwords are a good mechanism for security compared to other choices!
• Every password should be strong
• Every password should be unique per usecase (e.g. one password per website/host/etc) - this is generally solved through use of a password manager, security squid should be no different!
• Passwords can be shared - note this is a positive and a negative! For users, being able to share a password can be helpful - I don't care if my friend knows my password to some random pizza shop, and I might actively want to share netflix (or similar) passwords. For owners of websites like netflix where users sharing passwords directly impacts revenue, this is a negative
• Passwords separate out who a user is from what a user knows - this also has positives and negatives: for users, it means they can do things like have many concurrent accounts since their identity isn't linked to their account security
• Passwords can be backed up - this is in contrast to something like u2f
• Passwords can be changed cheaply
• Providing a password doesn't involve sharing additional, hard-to-change personal info - I don't want to provide a cell phone number to every website!
• If I go to a friend's house and want to use one of my passwords on their computer (e.g. log into netflix), I don't want their computer to have access to my complete password vault, even temporarily!

On UX

• Every security mechanism is only as good as its UX - very secure things which have a terrible UX will be ignored or bypassed
• The more unique steps or equipment your UX requires, the less likely it is to be used
• Displays and convenient UX are expensive to create - the bigger your display and device, the easier it is to make a good UX - this is why security squid is offloading to your cellphone as much as possible: security squid wants to be small!
• If I want to use one of my passwords on a friend's computer, I don't want to have them install software

On Interfaces/Connections

• Interfaces are generally where things like overflow vulnerabilities and breaks in your security model come from - parsing and translating untrusted input. As much possible, avoid having the secure domain (e.g. the SoC managing the passwords) interact directly with untrusted inputs (e.g. the host computer and/or cellphone)
• Bluetooth is notorious for having vulnerabilities - do not have integrated bluetooth on the IC which has direct contact with the password vault
• The flow of information should be as uni-directional as possible - there should be no way to exfiltrate the data through the wireless interface, or if a BLE keyboard interface is selected as necessary for UX, every password transmission should be confirmed with physical contact
• Backing up the entire password vault should only be possible via USB - though perhaps backup deltas could be done wirelessly
• Your cellphone should be able to receive the names of the websites and usernames, but *never* the passwords - the user should be able to send usernames and passwords to save in the vault, but should only be able to retrieve them via the keyboard interface

On Backups

• it has to be easy to back up your password vault, and it has to be encouraged automagically
• the backup can be "always online," so long as it's defended by something like a secure memory chip
• perhaps there should be a separate backup device?

Rough Architecture

While there are many details to how the system will be setup, the picture provides a very rough, high level design. Essentially, the system is comprised of 4 main components:

• an IC which serves as effectively a UART to BLE bridge - this is how the squid will talk to the phone
• a small (4MB?) flash chip which will hold the encrypted password database
• a secure enclave - probably the atecc608b - holds the key that can decrypt the password database
• an IC which will serve as the primary compute unit - its job is to interact with the backing storage, secure enclave, and BLE bridge to provide the main functionality

Secret Storage

• In an ideal world, we will hold as few secrets as possible - the user should provide the keys and that unlocks everything
• Strong enough keys to survive storage at rest cannot reasonably be derived from user input - look to how whole disk encryption works on linux: user password decrypts on-disk key; on disk key is what the data is actually encrypted with

Security Model

Threat Model: External Interfaces

There are 2 external interfaces we need to defend: USB to the host PC, and BLE to the phone.

The USB handling will be important to make sure that parsing failures and other sources of error don't lead to device compromise, but ideally we can use something like Rust to write the USB stack and avoid the majority of the types of bugs one might encounter writing a parser - we can crash the application on failures because a DDoS to the device is acceptable if we reveal no secrets.

The bluetooth interface is more complicated - the bluetooth stacks on the market are generally considered not secure, and so we would prefer to have any interface which touches bluetooth to be insulated from the Vault Manager IC (VMIC). To this end, we will have a second SoC which manages bluetooth called the RFIC. The VMIC will interface via a simple serial (UART) protocol, which will feature both a command and control (C&C) protocol as well as a data pass-through protocol. During regular operation, the UI Device/Phone will negotiate a secure channel with the VMIC, and the RFIC will simply see an encrypted packets which it will have no comprehension of the contents.

Threat Model: Physical Access

If you drop the device, someone who has prolonged physical access should not be able to access the stored passwords either by using the device nor accessing the underlying hardware. This leads to a number of different scenarios we need to defend against.

The first is that the data at rest has to be encrypted, and someone who gains access to that data should not be able to dump the data and access it. Much like whole disk encryption, we'll have both a data encryption key (DEK) and a key encryption key (KEK). Ideally, the data should not be brute-force decryptable in a reasonable timeframe - normally, this would be achieved by using something like an aggressive number of PBKDF2 rounds, but the VMIC will not have enough compute power to make this plausible when comparing against the hashing power of a modern CPU/GPU. Because of this, we store the DEK inside a secure enclave, which can only be accessed through I2C. We will take the user input, pass it through PBKDF2 for a number of rounds, then use that as the KEK to request that the secure enclave reveal the DEK. Because the only mechanism to confirm a guess of the KEK is through the secure enclave IC, an attacker's hashing capability is rendered nearly meaningless.

The next big threats relate to firmware/IC replacement attacks - assuming that the device firmware is possible to update, we act as if the device is possible to erase. Most devices allow for the entire device to be erased and reprogrammed, even when the flash is "locked." Ideally, we should be able to make the device inoperable if this happens, by pairing some key between the secure enclave and the VMIC flash. Thus, proper updates should be able to selectively erase flash sections and hostile flashes should be unable to maintain the secret in flash.

A similar mechanism is necessary for RFIC firmware replacement - the Secure Enclave and the Phone/UI Device need to be paired such that the RFIC cannot interfere, even if compromised. Thus we expect that the pairing procedure will involve a private-public key pair from both the secure enclave and the phone, and all future communication will be mutually authenticated. Since the firmware of the RFIC only has access to bluetooth packets, this mutual authentication guarantees that the RFIC being compromised should not be able to meaningfully impact security.