Security Squid - Revision history

Kscz at 15:37, 24 April 2025

2025-04-24T15:37:39Z

← Older revision		Revision as of 08:37, 24 April 2025
Line 1:		Line 1:

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

Kscz at 18:32, 20 April 2025

2025-04-20T18:32:59Z

← Older revision		Revision as of 11:32, 20 April 2025
Line 64:		Line 64:

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

Kscz at 00:35, 21 January 2023

2023-01-21T00:35:24Z

← Older revision		Revision as of 17:35, 20 January 2023
Line 60:		Line 60:

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

Kscz at 00:08, 21 January 2023

2023-01-21T00:08:22Z

← Older revision		Revision as of 17:08, 20 January 2023
Line 41:		Line 41:
	* 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		* 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 scribbles~~.png~~\|thumb~~]]		[[File:Security Squid High-level HW Architechture.png]]

	===Secret Storage===		===Secret Storage===
	* In an ideal world, we will hold as few secrets as possible - the user should provide the keys and that unlocks everything		* 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		* 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.

Kscz: /* Rough Architecture */

2023-01-12T20:00:36Z

Rough Architecture

← Older revision		Revision as of 13:00, 12 January 2023
Line 35:		Line 35:

	===Rough Architecture===		===Rough Architecture===
	[[File:Security squid scribbles.png\|~~frame~~]]		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 scribbles.png\|thumb]]

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

Kscz: /* Rough Architecture */

2023-01-12T19:47:38Z

Rough Architecture

← Older revision		Revision as of 12:47, 12 January 2023
Line 35:		Line 35:

	===Rough Architecture===		===Rough Architecture===
	[[File:Security squid scribbles.png\|~~10%px\|thumb~~]]		[[File:Security squid scribbles.png\|frame]]

Kscz: /* Rough Architecture */

2023-01-12T19:47:07Z

Rough Architecture

← Older revision		Revision as of 12:47, 12 January 2023
Line 35:		Line 35:

	===Rough Architecture===		===Rough Architecture===
	[[File:Security squid scribbles.png\|10%px]]		[[File:Security squid scribbles.png\|10%px\|thumb]]

Kscz: /* Rough Architecture */

2023-01-12T19:46:53Z

Rough Architecture

← Older revision		Revision as of 12:46, 12 January 2023
Line 35:		Line 35:

	===Rough Architecture===		===Rough Architecture===
	[[File:Security squid scribbles.png\|30%px]]		[[File:Security squid scribbles.png\|10%px]]

Kscz: /* Rough Architecture */

2023-01-12T19:46:41Z

Rough Architecture

← Older revision		Revision as of 12:46, 12 January 2023
Line 35:		Line 35:

	===Rough Architecture===		===Rough Architecture===
	[[File:Security squid scribbles.png\|50%px~~\|frame~~]]		[[File:Security squid scribbles.png\|30%px]]

Kscz: /* Rough Architecture */

2023-01-12T19:46:28Z

Rough Architecture

← Older revision		Revision as of 12:46, 12 January 2023
Line 35:		Line 35:

	===Rough Architecture===		===Rough Architecture===
	[[File:Security squid scribbles.png]]		[[File:Security squid scribbles.png\|50%px\|frame]]