Specifications

F-Secure Armory Drive

Introduction

This document describe the functioning of the F-Secure Armory Drive iOS app , running on the user Mobile Device (MD) and its interaction with the disk encryption firmware running on the USB armory (UA).

The companion app allows the user to safely unlock, over Bluetooth (BLE), an encrypted microSD inserted on the UA, on untrusted hosts (e.g. laptop) without exposing to it encryption keys.

After the unlock, the encrypted microSD is exposed to the host as a regular mass storage device.

Security model

The security model assumes that:

• The UA and MD are trusted when used together.

• The host where the UA is connected to is untrusted.

To this end the architecture is designed to satisfy the following requirements:

• The BLE traffic between the MD and the UA is protected from any possible interception over the air.

• The security of the communication between the MD and the UA do not rely on BLE security features. In other words security measures are implemented at application level.

• An attacker that gains physical access to a locked UA, cannot reconstruct the full key that unlocks the secure storage.

• An attacker that gains physical access to a locked UA, cannot retrieve its partial key without being able to execute authenticated code on the device (e.g. bypassing secure boot).

• An attacker that gains physical access to the user MD, cannot reconstruct the full key that unlocks the secure storage.

• An attacker that gains physical access to the user MD cannot retrieve its partial key without being able to unlock the UA first.

Pairing

The term "pairing" in the context of this document indicates key negotiation, between the UA and the MD, which allows the two parties to secure BLE communication.

The pairing process is summarized as follows:

1. The UA is plugged on the user host without an SD card inserted.

2. The user opens the companion app on the MD.

3. The companion app guides the user, step by step, in the pairing process.

4. The UA exposes a Mass Storage device with a single QR code image, which the MD scans in order to load the UA certificate on the companion app.

   The UA will expose the pairing QR code only if it is in an unpaired state.

5. The companion app locally generates the MD long-term key pair.

6. The companion app issues, over BLE, a pairing request sending the generated MD long-term public key to the UA.

7. The UA replies providing a proof that the MD long-term public key has been correctly received and stored on the UA.

At the end of the pairing process on the UA a visual feedback (i.e. change of the blinking/status LEDs) is provided to the user.

After completion of the pairing, the UA and the MD can protect (i.e. encrypt and authenticate) any further message exchanged over BLE.

Note that after completion of the pairing the UA must be restarted with an SD card inserted to exit pairing mode.

See Appendix A: Key Negotiation for more details regarding the cryptographic material that is exchanged during the pairing.

Key material

Three keys are involved in the unlock process of the encrypted drive:

• The Key Encryption Key (KEK), stored on the MD.
• The wrapped Data Encryption Key (DEK), stored on the UA.
• The unwrapped (i.e. plaintext) DEK, present on the UA only when it is unlocked.

The KEK is used to unwrap (i.e. decrypt) the Data Encryption Key (DEK) stored on the UA, the unwrapped DEK is the actual key used to encrypt and decrypt the data stored on the encrypted drive.

The unwrapping on the UA also uses an internal hardware-unique key in the process, to uniquely tie the DEK to the MD, through the KEK and the UA itself.

The companion app checks, at startup or after the pairing completion, if a KEK is already present in the MD keychain, otherwise a new one is generated.

The KEK is to be sent to the UA through an unlock request in order to decrypt the encrypted drive on the UA.

When an unlock request is sent to a paired UA, the USB armory derives the DEK which will be used to encrypt the cipher the drive, using the MD KEK as well as the MD long-term public key for diversification across pairings.

See APPENDIX B: Cryptographic Key Material.

Lock/Unlock

The companion app provides an intuitive graphical element to allow the user to perform lock/unlock of the encrypted drive on the UA.

>

When requested by the user, the companion app sends the KEK to the UA.

This unlock grants the user immediate access to all the content stored on the encrypted drive without requiring any further interaction with the companion app.

The lock operation detaches the exposed mass storage device, without invalidating the current session keys to allow further unlocks in the same session.

The UA provides visual feedback of the lock/unlock operations using its LEDs.

Recovery or migration to a new phone

The companion app implements two mechanisms for recovery or migration of its stored keys on a new MD:

• OS-level backup (e.g. iCloud Keychain)
• Manual backup via QR code to be exported/imported by the user

The recovery, or migration, of the companion app on a new MD is fully automated when OS-level backups are enabled.

To implement the manual backup, the companion app should provides the following functionalities:

• MD keys export.

  The key export produces a QR code image that can be displayed on the MD screen or saved as image file.

• MD keys import, provided as an alternative to a new pairing process.

The backup, recovery and migration to a new MD of the companion app is a local process, performed within the companion app. In other words no interaction with the UA is required.

Warning

These recovery procedures do not provide protection in case of failures or data loss on the UA.

Key wipe

The companion app allows the user to delete a pairing and all associated data.

Firmware update

USB armory firmware updates can be downloaded here and applied as follows.

1. The UA is plugged on the user host without an SD card inserted.

2. The firmware binary must be copied over the exposed UA mass storage device.

3. The UA mass storage device must be ejected by the host, this triggers the firmware update process.

4. A blinking white LED indicates firmware update in progress, the white LED turns off on success, the blue LED remains solid on errors.

5. The UA must be unplugged.

Session diagram

BLE transport

The application protocol protobuf messages are exchanged using the BLE Serial Port Service (SPS) protocol as described by the UA BLE module manufacturer.

Flow control with "credits", per SPS specifications" is enabled for reliable operation.

BLE SPS Specifications (u-blox)

BLE SPS iOS Implementation Example (u-blox)

In order to send and receive packets with sizes exceeding the maximum packet size (SPS MTU is 244 bytes assuming that the BLE Data Length Extension is enabled), fragmentation happens outside the protobuf layer.

Each packet sent over BLE SPS includes an header containing the total number of fragments as well as the fragment sequence number (starting from 1).

total	seq	envelope fragment
uint8	uint8	bytes[0:241]

Message envelopes smaller or equal than 242 bytes should be sent in a single packet.

The last fragment always has identical total and seq values.

Example 1: Single 80 bytes message.

pkt 1: 01 01 AA BB CC DD EE FF ...

Example 2: Fragmented 500 bytes message.

pkt 1: 03 01 AA BB CC DD EE FF ...
pkt 2: 03 02 AA BB CC DD EE FF ...
pkt 3: 03 03 AA BB CC DD EE FF ...

BLE application protocol

The message exchange between the UA and the MD is implemented through asynchronous requests/responses which contain data serialized using protocol buffers.

The structures of the protocol buffers are described in the accompanying armory.pro definition, compliant to Protobuf Version 3.

Multiple USB armory support

A single MD supports multiple UAs, therefore the MD companion supports separate views to allow connection to separate UAs.

The MD key material is different for each UA profile.

Appendix A: Key negotiation

Pairing

1. UA generates a QR code containing the UA long-term EC public key and an ephemeral random pairing nonce (64-bit).

   The data embedded in the QR code is signed (ECDSA) using the UA long-term EC private key.

   The QR code is exposed to the host PC through an image file stored on the USB mass storage that should be scanned with the MD camera and imported in the companion app.

2. MD decodes the QR code, verifies the ECDSA signature and extracts the random pairing nonce and UA certificate.

3. MD sends a pairing request (including the MD long-term EC public key) to the UA with the previously received pairing nonce.

   The message is signed (ECDSA) using the MD long-term EC private key.

4. UA verifies the ECDSA signature and matches the nonce with the previously sent one, and sends a positive pairing response to the MD to confirm that the first session can be negotiated.

   NOTE: at this stage a malicious MITM would not be detected unless step 4 response would include a signed nonce and the MD public key (or its hash) for MD verification. MITM is anyway detected in step 7.

Session Key Negotiation

5. UA and MD generate their ephemeral EC key pairs.

6. The MD sends to the UA its ephemeral EC public key to the UA in a message signed with its long-term EC private key.

   The UA verifies the signature and stores the received public key.

7. The UA replies to the MD sending its ephemeral EC public key and a fresh nonce (for later HKDF) in a message signed with its long-term EC private key.

   The MD verifies the signature, stores the nonce and received public key.

8. UA and MD mutually perform ECDHE and compute a pre-master secret using the peer ephemeral public key and own ephemeral private key.

9. Both peers derive a 256-bit shared secret applying HKDF (key derivation function) to the agreed pre-master secret and the random nonce exchanged in step 7.

10. The two peers can now exchange command/responses using the agreed 256-bit symmetric session key for payload AES-256 encryption. The message envelopes are signed/verified with the respective ephemeral private/public keys.

New sessions can be negotiated at any time by the MD, invalidating the previous one. Sessions are volatile and therefore not persistent across UA reboots.

NOTE on 1: The QR code includes the UA BLE module name. This allows the companion app to know in advance the name of the UA to connect to without requiring to prompt to the user.

NOTE on 9: Applying a secure key derivation function (KDF) to the raw Diffie–Hellman shared secret is necessary to avoid leaking information about the static private key. The hashing algorithm involved in the KDF also guarantee to remove any weak bits due to the Diffie-Hellman exchange (HKDF key derivation algorithm KDF based on SHA-256 should be used).

wikipedia: Elliptic curve Diffie-Helmman

NOTE on 8: The described ECDHE key agreement protocol does not provide any intrinsic protection against replay attacks within an established session. Thus, a replay attack protection (eg. timestamp) is included and validated within every message exchanged between the UA and the MD.

Appendix B: Cryptographic key material

The following table summarizes all required certificates and keys stored across the MD and the UA.

Type	Algorithm	Location	Role	Generated¹
UA long term	ECDSA (secp256r1)	UA (pair), MD (public)	peer authentication²	Yes
MD long term	ECDSA (secp256r1)	MD³ (pair), UA (public)	peer authentication²	Yes
UA ephemeral	ECDSA (secp256r1)	UA (pair), MD (public)	session key negotiation and authentication	Yes
MD ephemeral	ECDSA (secp256r1)	MD (pair), UA (public)	session key negotiation and authentication	Yes
session key	AES-256-OFB	UA, MD	session encryption	Yes
MD KEK	AES-128	MD³	encrypted drive unlock	Yes
wrapped DEK	AES-128	UA	encrypted drive unlock	Yes
DEK	AES-128	UA (volatile while unlocked)	encrypted drive unlock	Yes

¹ Not shipped in factory state, created during initialization or at pairing.

² Also used for message signing and authentication (ECDSA) for messages outside an established session (i.e. pairing, opening a new session).

³ Keys stored in the MD keychain and exported in the recovery QR code or saved on OS backup if enabled.

Appendix C: QR code format

QR code version 40 ECC M (177x177) can embed a sufficient amount of data that would be required by the MD (i.e. pairing and recovery QR codes).

The followings are the number of alphanumeric characters that can be embedded in a 40 ECC M QR code depending by the chosen error correction level:

4296 (L)
3391 (M) <
2420 (Q)
1852 (H)

M is the typical Error Correction Level used if no special needs are required, it appears to be the appropriate choice also in the case of the MD.

A QR code is used to communicate to the MD the following information:

• pairing data: device name, nonce, UA long-term EC public key, signature
• recovery data: device name, UA long-term EC public, key, MD keys (EC private, EC public, KEK)

The data embedded by the QR code represents protobuf messages, defined in the accompanying qr.proto definition file.

License

Copyright (c) WithSecure Corporation

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation under version 3 of the License.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

See accompanying LICENSE file for full details.