‐x DESIGN: FIDO2 Gate2 workflow and F2G2 Demonstrator app specifications - glenw921/TripleCrypt GitHub Wiki
DEPRECATED! FIDO2 does not provide inviolable authentication with a secure server. PIV has not JavaScript/browse accessible API libraries.
(See G2F2 Demonstrator specifications document attached at bottom of this page.)
-------------- From dialog with "o1 Guide: PWAs & 2FA 001" --------------------
I SAID:
Good work! Let us name the solution/workflow you just described for creating an inviolable FIDO2 encryption/decryption sequence for TripleCrypt the "FIDO2 Gate" - other components of authentication such as passwords and PINs are a broader issue beyond the FIDO2 Gate. Under "Additional Considerations" you mentioned the use of a PIV capable FIDO2 device for storage of keys and other critical data. Please elaborate on this topic and update the FIDO2 Gate to assume/require PIV capable device so that we maximize safe storage of critical data.
ChatGPT said:
Thank you for the feedback! Let’s now enhance the FIDO2 Gate by incorporating PIV (Personal Identity Verification) capabilities to store critical cryptographic keys securely within the FIDO2 hardware device. By requiring a PIV-capable device, such as a YubiKey with PIV support, we can leverage this functionality to maximize the security of key storage and ensure that all critical data is protected by the hardware.
What is PIV (Personal Identity Verification)? PIV is a smart card standard used for secure authentication, encryption, and digital signing. Many PIV-capable FIDO2 devices, like the YubiKey 5 Series, implement this standard alongside FIDO2/WebAuthn to allow storage of asymmetric keys (public/private key pairs) directly on the device.
By using the PIV applet in the hardware key, you can store encryption keys (e.g., RSA, ECC) and perform cryptographic operations like encryption, decryption, and signing directly on the device, similar to a smart card. This allows sensitive cryptographic operations to be offloaded from the browser or software to the hardware for maximum security.
Key Benefits of Using PIV with FIDO2: Key Pair Storage on the Hardware Device: The PIV capability allows for storing multiple public/private key pairs (e.g., RSA, ECC) within the hardware key. These keys can be used for encryption, decryption, and signing of data, ensuring that the private keys never leave the device. Hardware-Level Cryptography: Cryptographic operations involving the private key (e.g., decrypting or signing) are performed directly on the device, ensuring that even if the PWA is compromised, attackers cannot access the raw cryptographic keys. Isolation of Critical Data: Keys and critical data stored in the PIV applet of the FIDO2 device are isolated from the host system (e.g., the browser or the PWA running on the device). Only authenticated users with physical access to the hardware device can trigger these cryptographic operations. Enhanced FIDO2 Gate Workflow Using a PIV-Capable Device Let’s now update the FIDO2 Gate architecture to assume the use of a PIV-capable FIDO2 device (e.g., YubiKey 5 Series) to store and protect critical encryption keys, while leveraging its FIDO2 capabilities for user authentication. This will maximize safe storage of cryptographic material and critical data.
Updated Workflow of the FIDO2 Gate with PIV Support: Encryption Process: Generating the Symmetric Key (AES Key):
The PWA generates a symmetric encryption key (e.g., AES-256) to encrypt the file content (e.g., MySecrets.tc3). Encrypting the Symmetric Key with the PIV Key:
The PWA then sends this symmetric key to the PIV-capable FIDO2 device. The PIV applet on the device uses a PIV-stored public key to encrypt the symmetric key. The corresponding private key, securely stored within the PIV applet, will later be used to decrypt this symmetric key. The encrypted symmetric key is stored alongside MySecrets.tc3 or in local storage. Encrypting the Document (MySecrets.tc3):
The PWA uses the symmetric key to encrypt the file’s content locally. The encrypted document (MySecrets.tc3) and the encrypted symmetric key are now both stored safely. Decryption Process (Using the PIV-Capable FIDO2 Device): Retrieving the Encrypted Symmetric Key:
When the user attempts to decrypt MySecrets.tc3, the PWA retrieves the encrypted symmetric key from the file metadata or local storage. Using FIDO2 for Authentication:
The FIDO2 key is used for local authentication to verify the user's identity before allowing access to the critical decryption process. The FIDO2 WebAuthn process involves a challenge-response mechanism where the FIDO2 private key signs a challenge from the PWA to authenticate the user. This ensures that only the rightful user with physical access to the FIDO2 key can proceed. Decrypting the Symmetric Key Using the PIV Applet:
After successful authentication, the PWA sends the encrypted symmetric key to the PIV-capable FIDO2 device. The PIV applet uses the PIV-stored private key (which corresponds to the public key used for encryption) to decrypt the symmetric key. This decryption happens entirely within the hardware. Decrypting the Document:
Once the PWA retrieves the decrypted symmetric key from the FIDO2 device, it can use this key to decrypt MySecrets.tc3 locally, allowing the user to view the file’s contents. How the PIV-Capable FIDO2 Device Enhances Security in the FIDO2 Gate:
- Storage of Cryptographic Keys: The symmetric encryption key is protected by encryption using the PIV public/private key pair stored on the FIDO2 device. This ensures that even if an attacker gains access to the PWA or encrypted file (e.g., MySecrets.tc3), they cannot decrypt the symmetric key without access to the physical FIDO2 key.
- Hardware-Backed Decryption: All decryption operations involving the private key are performed directly on the FIDO2 device, ensuring that the private key never leaves the device and is not exposed to the host system or PWA. This makes it nearly impossible for an attacker to extract the private key, even if they have access to the client-side code.
- Protection Against Tampering: Even if the attacker modifies or circumvents parts of the PWA, they cannot bypass the requirement to use the PIV-protected private key to decrypt the symmetric encryption key. This is because the cryptographic operation depends on the private key stored inside the hardware device.
- Multi-Factor Protection: The FIDO2 Gate with PIV support still allows for multi-factor protection, such as requiring a PIN to access the FIDO2 device’s PIV applet. This adds another layer of security to prevent unauthorized use of the device for decryption. Summary of the Enhanced FIDO2 Gate with PIV Support: PIV-Stored Public/Private Key Pairs: The FIDO2 device stores the public/private key pairs used for encrypting and decrypting the symmetric key needed for document encryption. Symmetric Key Protection: The symmetric encryption key is encrypted using the PIV public key and can only be decrypted by the PIV private key stored on the device. Inviolable Hardware-Based Decryption: All sensitive cryptographic operations involving the private key happen on the hardware device itself, ensuring that keys are never exposed to the host system. FIDO2 Authentication: The FIDO2 key still performs local authentication to verify the user before proceeding with decryption, ensuring that only authorized users can unlock the encryption keys. Multi-Factor Security: Additional layers like PIN protection can be applied to the PIV applet, adding extra security for accessing cryptographic operations. How to Implement: YubiKey 5 Series: YubiKeys supporting PIV (like YubiKey 5 NFC, YubiKey 5C NFC, YubiKey 5Ci) would be ideal for this workflow. They support both FIDO2/WebAuthn and PIV, allowing you to store public/private key pairs securely and use them in cryptographic operations. PIV Management Tools: Use tools like YubiKey Manager to generate and manage PIV keys, assign PINs for PIV access, and ensure that private keys remain securely on the device. Browser Compatibility: The PWA would use the WebAuthn API for FIDO2 authentication and additional libraries (e.g., PKCS#11 or custom JavaScript) to interface with the PIV applet for encryption and decryption. By incorporating PIV-capable devices into the FIDO2 Gate, we significantly enhance the security of key storage, making it resistant to tampering, theft, or modification even in an offline, client-side environment.
Let me know if you'd like more technical details on PIV integration or specific guidance on using YubiKeys with TripleCrypt!
I SAID:
Let's call this new approach and workflow, which you just described, "FIDO2 Gate2". I have some questions about FIDO2 Gate: (1) Can the "symmetric encryption key" (SEK) used for document encryption be stored in the PIV FIDO2 device after it has also been encrypted by the hardware key? (2) Given that the encrypted SEK (eSEK) cannot be used to decrypt MySecrets.tc3 until the SEK has itself been decrypted on/by the hardware key, why is any user authentication required in the workflow? I understand that usage of a PIN adds security, but I'm wondering if FIDO2 Gate2 could be used without ANY "user authentication" steps. I'm just wondering about the technical issues here, not the "secure design and good user verification" issues.
ChatGPT said:
Great! Let's dive into your questions regarding FIDO2 Gate2, with a focus on the technical mechanics of encryption and the role of user authentication.
(1) Can the "symmetric encryption key" (SEK) used for document encryption be stored in the PIV FIDO2 device after it has also been encrypted by the hardware key? In FIDO2 Gate2, the symmetric encryption key (SEK) is initially used to encrypt the document (e.g., MySecrets.tc3) and is then encrypted using a PIV-stored public key from the hardware device (e.g., YubiKey). This ensures that the symmetric key is protected by hardware-backed encryption.
Storing the eSEK on the PIV FIDO2 Device: Yes, technically, you could store the eSEK directly on the PIV-capable FIDO2 device. Here’s how this could work:
PIV Slots: A typical PIV-capable FIDO2 device (like YubiKey 5 Series) has multiple slots for storing key pairs and certificates. However, these slots are primarily used to store asymmetric key pairs (e.g., RSA, ECC) rather than large data blocks like encrypted symmetric keys.
Storing Encrypted Data in PIV: PIV-capable devices do not have a specific slot designed for storing large amounts of encrypted data such as an AES symmetric key (especially after encryption). The PIV slots are used to store certificates, public/private key pairs, or perform cryptographic operations.
Possible Alternative: You can store the eSEK in the PIV device's data objects (assuming the size of the eSEK is small enough to fit in the available storage space). However, typically, MySecrets.tc3 would store the eSEK along with the encrypted document or within a safe local storage (e.g., IndexedDB).
Summary: Direct storage of the eSEK on the PIV-capable device is not typically supported, as PIV slots are reserved for public/private keys and certificates. The eSEK is usually stored alongside the encrypted document in local storage, ensuring it remains available for decryption using the hardware key. (2) Given that the eSEK cannot be used to decrypt MySecrets.tc3 until the SEK has itself been decrypted on/by the hardware key, why is any user authentication required in the workflow? Could FIDO2 Gate2 be used without ANY "user authentication" steps? You raise an excellent point about the decryption dependency on the hardware key, and it leads to an important technical observation:
Decryption Process in FIDO2 Gate2: The eSEK cannot be used to decrypt MySecrets.tc3 until the PIV-capable hardware key successfully decrypts the SEK using the private key stored inside the device. The SEK decryption is fully dependent on the hardware key performing the cryptographic operation, which involves using the private key stored in the PIV applet. This guarantees that the decryption process requires the hardware key to operate properly. Why User Authentication is Typically Required: FIDO2 and PIV Security Design:
FIDO2/WebAuthn typically requires a user authentication step (such as PIN or biometric) to verify that the user in possession of the FIDO2 key is the rightful owner. This is crucial in environments where multi-factor authentication (MFA) is needed to ensure that a user proves their identity before accessing sensitive resources. PIV standards also emphasize user verification steps like a PIN, which is used to ensure that even if the device is stolen, an attacker cannot simply plug it in and use it without first verifying themselves. Technical Use Without User Authentication:
Technically, FIDO2 Gate2 could be implemented without requiring user authentication. If you omit PIN or user interaction, the hardware key would still function correctly, as the private key on the FIDO2 device is used automatically to decrypt the SEK However, this would bypass an important layer of security. Without user authentication:
The decryption workflow would automatically proceed as long as the hardware key is present, making it more convenient for the user. The hardware key would perform the decryption of the SEK, allowing the PWA to decrypt MySecrets.tc3 without verifying the user's identity. Technical feasibility: Yes, PIV or FIDO2 authentication can be set up to operate without requiring user interaction (like a PIN or biometric verification), but this weakens the security model by eliminating the user verification step.
Key Points: Technically, FIDO2 Gate2 could work without any user authentication steps (like a PIN) because the decryption of the SEK relies solely on the hardware key's private key. As long as the hardware key is connected to the system, the cryptographic operations can proceed.
Practically, removing user authentication weakens the security of the system. The absence of a user authentication step (e.g., PIN or biometric verification) means that anyone in possession of the hardware key would be able to decrypt the content without needing additional factors to prove ownership of the key.
Conclusion: (1) The symmetric encryption key (SEK) can technically be encrypted using the PIV private key but is not typically stored within the PIV device itself. Instead, the encrypted SEK (eSEK) is stored alongside the encrypted document in local storage or as metadata in MySecrets.tc3.
(2) FIDO2 Gate2 can technically operate without user authentication (i.e., without a PIN or biometric verification), since the PIV private key will still be used to decrypt the SEK on the hardware device. However, this weakens the security model by removing the user identity verification step, which is a crucial part of ensuring that only the rightful owner can access the data. While user authentication isn’t technically required for decryption to occur, it's strongly recommended in secure designs. [GW: This statement was later contradicted by o1, claiming that all PIV operations require user authentication. G2F2 Demonstrator app will examine the truth.]