From a75d272f4a92c7d591ccfcd35a6e2567c3aa2696 Mon Sep 17 00:00:00 2001 From: Conor Patrick Date: Wed, 23 Jan 2019 19:53:58 -0500 Subject: [PATCH] move files, not yet implemented masked aes --- docs/fido2-impl.md | 2 ++ docs/signed-updates.md | 26 -------------------------- docs/solo/fido2-impl.md | 4 +++- docs/solo/signed-updates.md | 4 ++-- 4 files changed, 7 insertions(+), 29 deletions(-) delete mode 100644 docs/signed-updates.md diff --git a/docs/fido2-impl.md b/docs/fido2-impl.md index 2bd5866..a5c8ba4 100644 --- a/docs/fido2-impl.md +++ b/docs/fido2-impl.md @@ -57,6 +57,8 @@ keys which are then used for FIDO2/U2F. --> ## Key derivation +** Planned, but not yet implemented. ** + Master secret `M` consists of 64 bytes, split into equal parts `M1` and `M2`. In theory, we should only need 32 bytes to achieve 256 security, but we also plan to have side channel security hence the added bytes. diff --git a/docs/signed-updates.md b/docs/signed-updates.md deleted file mode 100644 index 39eae90..0000000 --- a/docs/signed-updates.md +++ /dev/null @@ -1,26 +0,0 @@ - -Solo has a bootloader that's fixed in memory to allow for signed firmware updates. It is not a built-in bootloader provided by the chip -manufacturer, it is our own. We plan to use Ed25519 signatures, which have [efficient constant-time implementations on Cortex-M4 chips](http://www.cs.haifa.ac.il/~orrd/LC17/paper39.pdf). - -On the STM32L432, there is 256 KB of memory. The first 14 KB of memory is reserved for the bootloader. -The bootloader is the first thing that boots, and if the button of the device is not held for 2 seconds, the -application is immediately booted. - -Consider the following memory layout of the device. - -| 14 KB | 226 KB | 16KB | -|---|---|---| -| --boot-- | -------application------- | --data-- | - -Our bootloader resides at address 0, followed by the application, and then the final 16 KB allocated for secret data. - -The bootloader is allowed to replace any data in the application segment. When the application is first written to, -a mass erase of the application segment is triggered and a flag in the data segment is set indicating the application -is not safe to boot. - -In order to boot the application, a valid signature must be provided to the bootloader. The bootloader will verify the -signature using a public key stored in the bootloader section, and the data in the application section. If the signature -is valid, the boot flag in the data section will be changed to allow boot. - -We are working to make the signature checking process redundantly to make glitching attacks more difficult. Also random delays -between redundant checks. diff --git a/docs/solo/fido2-impl.md b/docs/solo/fido2-impl.md index d0d5890..2bd5866 100644 --- a/docs/solo/fido2-impl.md +++ b/docs/solo/fido2-impl.md @@ -15,13 +15,15 @@ A master secret, `M`, is generated at initialization. This is only used for all key generation and derivation in FIDO2. Solo uses a key wrapping method for FIDO2 operation. +** NOTE: The masked implementation of AES is planned, but not yet implemented. Currently it is normal AES. ** + ## Key wrapping When you register a service with a FIDO2 or U2F authenticator, the authenticator must generate a new keypair unique to that service. This keypair could be stored on the authenticator to be used in subsequent authentications, but now a certain amount of memory needs to be allocated for this. On embedded -devices, there isn't much memory to spare and users will always frustratingly +devices, there isn't much memory to spare and users will allows frustratingly hit the limit of this memory. The answer to this problem is to do key wrapping. The authenticator just diff --git a/docs/solo/signed-updates.md b/docs/solo/signed-updates.md index 86dba1d..39eae90 100644 --- a/docs/solo/signed-updates.md +++ b/docs/solo/signed-updates.md @@ -22,5 +22,5 @@ In order to boot the application, a valid signature must be provided to the boot signature using a public key stored in the bootloader section, and the data in the application section. If the signature is valid, the boot flag in the data section will be changed to allow boot. -Signature checks and checks to the data section boot flag are made redundantly to make glitching attacks more difficult. Random delays -between redundant checks are also made. +We are working to make the signature checking process redundantly to make glitching attacks more difficult. Also random delays +between redundant checks.