kitwiki - User contributions [en]

Security Squid

2025-04-24T15:37:39Z

Kscz:

Security Squid is the name for a hardware-based password manager inspired by [https://www.themooltipass.com/ 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.

==Project Description==
Plug in a device which looks like a USB thumb-drive in size and shape. Pull out your phone - connect to the device via BLE.

On your phone, select the name of the website you're trying to login to.

Press the "username" button, and the device will pretend to be a keyboard and type in your username. Press the password button and it will type in your password.

==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

[[File:Security Squid High-level HW Architechture.png]]

===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.

====Physical Attacks Ignored====
We're not assuming that there's a scenario where you are interacting with the device and an attacker can do complex analysis while you're decrypting the store. It is assumed the following attacks are not feasible without cooperation of the owner of the SecuritySquid
* Differential power analysis - the power comes from the host computer and the control signals for the decryption come from the phone, so an attacker should be unable to competently evaluate because they will lack timing information and context
* Timing attacks - similar to differential power analysis, an attacker that controls the USB interface should be unable to trigger the large number of repeated decryptions to successfully pull this off

Security Squid

2025-04-20T18:32:59Z

Kscz:

Security Squid is the name for a hardware-based password manager inspired by [https://www.themooltipass.com/ 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

[[File:Security Squid High-level HW Architechture.png]]

===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.

====Physical Attacks Ignored====
We're not assuming that there's a scenario where you are interacting with the device and an attacker can do complex analysis while you're decrypting the store. It is assumed the following attacks are not feasible without cooperation of the owner of the SecuritySquid
* Differential power analysis - the power comes from the host computer and the control signals for the decryption come from the phone, so an attacker should be unable to competently evaluate because they will lack timing information and context
* Timing attacks - similar to differential power analysis, an attacker that controls the USB interface should be unable to trigger the large number of repeated decryptions to successfully pull this off

ATA Design

2024-01-02T21:23:58Z

Kscz:

This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).

== MCU/Processor Selection ==
There needs to be a main processor, and this section runs through my thoughts as I consider the available options.

=== Linux-capable ===
Being Linux-capable would be nice! It's not a requirement because... well we don't need it!

The big downsides to Linux-capability are:
* Complexity - these parts require a lot more support circuitry
* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities; cheaper linux-capable processors like Allwinner's stuff is hard to get from trustworthy sources like Digikey/Mouser
* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules
* Real-time issues - making sure you get consistently paced DAC readings and push out consistent ADC updates may require extra support from the audio chipset
* GPIO limitations - we may need a separate low-power MCU to control the real-time bits/interface with higher-power domains as linux-capable MCUs generally don't have much GPIO strength

Big upsides:
* Libraries - most of the software will be done for free, we'll basically be plugging lego blocks together for most of it
* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware
* CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up
* Memory - pretty much every linux-capable setup will have more than enough RAM to run several SIP streams simultaneously

For a quick rundown of the complexities of building a linux-capable system: https://jaycarlson.net/embedded-linux/

=== Processor Capabilities ===
I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!

==== Connectivity ====
At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:
* TI's ARM-R5 line and TMC129x line (Cortex-M4F)
* NXP has a few offerings in the LPC line, Kinetis/MK line, and the MIMXRT line
* Microchip/Atmel has a bunch of offerings - a number of ARM9 and Cortex-A5/A7 linux-capable units, and the ATSamE53x (Cortex-M4F, 120Mhz) and ATSamE7x (Cortex-M7, 300Mhz) lines
* Espressif currently only has the original ESP32 with ethernet, though for reasons described below, I'll keep the ESP32-S3 in the running as well
* Allwinner - I don't feel super confident evaluating these options, and so I've left them off
* RaspberryPi
* Beaglebone Black/Green

It would be nice to have WiFi, but I couldn't find any options for this aside from the the ESP32. Any option could be paired with an ESP32-C3/ESP8266 to provide wifi.

All options could be paired with something like an SPI-to-ethernet adapter. The esp-idf supports a number of such devices - https://github.com/espressif/esp-idf/blob/master/components/esp_eth/include/esp_eth_phy.h

==== Decode/Encode ====
The MCU/Processor should be powerful enough to handle a few ports worth of real-time audio - this will require some benchmarking! I think this will disqualify most MCUs which don't have a FPU, but I am unsure.

How powerful the MCU is sets which codecs we can support and how many FXS ports our ATA can handle.

RAM utilization also needs to be tested - multiple concurrent encode/decode streams, along with SIP management will probably require a fair bit of memory.

==== Audio input/Output ====
The MCU/Processor will either need a really good ADC and DAC per FXS port we support, or it will need to support interfaces which can run to DAC/ADC audio devices. This should probably mean I2S support, but I need to do a deeper dive on it.

==== Ease of Assembly ====
When building these boards, it would be convenient to have an option which doesn't require complex soldering. This would effectively limit us to boards which have easy-to-utilize, cheap devboards - the beaglebone/raspberrypi (we would build this as a cape/hat), the teensy4 and the i.mxrt106x, or the ESP32 and its many variants. I'm not sure how strongly we should adhere to this idea.

ATA Design

2024-01-02T21:14:44Z

Kscz:

This page is about building an analog telephone adapter (ATA) which is wholly open-source and easily hack-able/adaptable to unusual use-cases (like payphones).

== MCU/Processor Selection ==
There needs to be a main processor, and this section runs through my thoughts as I consider the available options.

=== Linux-capable ===
Being Linux-capable would be nice! It's not a requirement because... well we don't need it!

The big downsides to Linux-capability are:
* Complexity - these parts require a lot more support circuitry
* Availability - pre-made modules like the RaspberryPi are hard to get a hold of in reasonable quantities; cheaper linux-capable processors like Allwinner's stuff is hard to get from trustworthy sources like Digikey/Mouser
* Cost - these will be more expensive to manufacture and/or require more-expensive pre-made modules

Big upsides:
* Libraries - most of the software will be done for free, we'll basically be plugging lego blocks together for most of it
* Scriptability/hackability - people will be able to use/modify/add behaviors without recompiling firmware
* CPU power - if we need to run several encode/decode streams, pretty much everything linux-capable will be able to keep up
* Memory - pretty much every linux-capable setup will have more than enough RAM to run several SIP streams simultaneously

For a quick rundown of the complexities of building a linux-capable system: https://jaycarlson.net/embedded-linux/

=== Processor Capabilities ===
I'm making the decision up-front to ignore anything in the 8-bit or 16-bit category. While it may be possible to make it work, for a project I'm doing for fun, I don't want to spend my time hyper-optimizing just to get basic functionality working. This means I won't be looking at the Microchip PIC8/12/14/16/18, the Atmel Atmega line, or TI's MSP430. What it leaves on the table is: Arm (bunch of manufacturers), Microchip's dsPIC line, Risc-V, and the ESP32-variants using the Xtensa CPUs. There may be others, but this is all I'm considering to start, mostly because it's what I know!

==== Connectivity ====
At a bare minimum, we'd like everything to have Ethernet. This is actually quite limiting! Things which still qualify:
* TI's ARM-R5 line and TMC129x line (Cortex-M4F)
* NXP has a few offerings in the LPC line, Kinetis/MK line, and the MIMXRT line
* Microchip/Atmel has a bunch of offerings - a number of ARM9 and Cortex-A5/A7 linux-capable units, and the ATSamE53x (Cortex-M4F, 120Mhz) and ATSamE7x (Cortex-M7, 300Mhz) lines
* Espressif currently only has the original ESP32 with ethernet, though for reasons described below, I'll keep the ESP32-S3 in the running as well
* Allwinner - I don't feel super confident evaluating these options, and so I've left them off
* RaspberryPi
* Beaglebone Black/Green

It would be nice to have WiFi, but I couldn't find any options for this aside from the the ESP32. Any option could be paired with an ESP32-C3/ESP8266 to provide wifi.

All options could be paired with something like an SPI-to-ethernet adapter. The esp-idf supports a number of such devices - https://github.com/espressif/esp-idf/blob/master/components/esp_eth/include/esp_eth_phy.h

==== Decode/Encode ====
The MCU/Processor should be powerful enough to handle a few ports worth of real-time audio - this will require some benchmarking! I think this will disqualify most MCUs which don't have a FPU, but I am unsure.

How powerful the MCU is sets which codecs we can support and how many FXS ports our ATA can handle.

RAM utilization also needs to be tested - multiple concurrent encode/decode streams, along with SIP management will probably require a fair bit of memory.

==== Audio input/Output ====
The MCU/Processor will either need a really good ADC and DAC per FXS port we support, or it will need to support interfaces which can run to DAC/ADC audio devices. This should probably mean I2S support, but I need to do a deeper dive on it.

==== Ease of Assembly ====
When building these boards, it would be convenient to have an option which doesn't require complex soldering. This would effectively limit us to boards which have easy-to-utilize, cheap devboards - the beaglebone/raspberrypi (we would build this as a cape/hat), the teensy4 and the i.mxrt106x, or the ESP32 and its many variants. I'm not sure how strongly we should adhere to this idea.

ATA Design

2024-01-02T20:32:46Z

Kscz: /* Linux-capable */

2023-01-20T07:22:13Z

Security Squid

2023-01-05T07:54:40Z

Kscz:

File:Pip unsure scaled.jpg

2023-01-05T07:54:28Z