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