Skip to content

Instantly share code, notes, and snippets.

@phagara

phagara/aem-gsoc-proposal.md Secret

Created April 2, 2017 14:43
Show Gist options
  • Save phagara/f6274dd4a3cc1872bc3bf42c207d64e9 to your computer and use it in GitHub Desktop.
Save phagara/f6274dd4a3cc1872bc3bf42c207d64e9 to your computer and use it in GitHub Desktop.
Download ZIP
Qubes OS AEM improvement GSoC project proposal
Raw
aem-gsoc-proposal.md

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Introduction

Anti Evil Maid (AEM) is an opt-in feature of the Qubes OS project aiming to provide resistance against so called evil maid type of security circumvention attacks, when an attacker has physical access to target computer.

The current implementation of AEM protection in Qubes OS does not offer any protection whatsoever against shoulder surfing or video surveillance based attacks (referred to as "observation attacks" throughout this document), as both the static trusted boot secret text or image unsealed by the Trusted Platform Module (TPM) and the disk encryption passphrase are seen in the clear on the screen or keyboard, respectively. This allows an evil maid attacker to either modify the boot process and insert a malicious payload while still showing the right (known by the attacker) static secret or to trivially decrypt computer storage using captured passphrase.

This Google Summer of Code (GSoC) project aims to substantially reduce the impact of observation attacks by changing the way TPM is used for machine to user authentication from simple visual static secret verification to a method resistant to such attacks. Similarly, the user to machine authentication is upgraded from a simple passphrase to two factor authentication (2FA) so that an attacker knowing only the passphrase cannot compromise the system.

Given the unique security properties and capabilities of TPM devices, multiple possible avenues for machine to user authentication present themselves. For instance, the TPM can be used to unseal a secret seed for time based one time passphrase (TOTP) generator, a six digit output of which the user would verify on a separate 2FA device (perhaps a closely guarded smartphone with TOTP application). As for the options of user to machine authentication, TPM-sealed and passphrase-protected Linux Unified Key Setup (LUKS) key files could be used. An attacker would then have to both know the passphrase and obtain a copy of the key file itself, which would be again stored on a small device the user always carries with them and plugs into the computer only after a verified trusted boot.

Additionally to the GSoC project idea written by the Qubes OS team, this proposal strives to also (and primarily) provide the best possible user experience (UX) for users whose threat model does not include multistage software based evil maid attacks.

Project goals

The main goal of this GSoC project is to substantially reduce the impact of observation attacks against an AEM enabled Qubes OS installations while not unnecessarily increasing the user perceived complexity of AEM boot process. This goal will be achieved by implementing support for and documenting opt-in machine to user authentication mechanism leveraging Intel Trusted eXecution Technology (TXT) dynamic root of trust measurement (DRTM) and TPM assisted measured boot to unseal a LUKS key file stored on removable media. The LUKS key file will be protected by an additional passphrase in order to provide user to machine authentication mechanism. Fallback support must also be developed to allow recovery in case of LUKS key file loss or unavailability.

Since the primary goal implementation will not be able to fully protect users whose threat model includes multistage software based evil maid attacks, the following features listed should also be implemented either during the three month GSoC work period (should the time permit) or at any point before or after the event.

Stretch goals are to implement, document and provide fallback options for:

  • opt-in usage of TOTP tokens for machine authentication
  • opt-in storing TPM-sealed and passphrase-protected LUKS key file on a secondary AEM media (inserted only after TOTP code verification)

Both of the above features trade ease of use for increased resistance against software based multistage evil maid attacks. However, while not completely preventing such attacks, they do extend the attack surface by requiring multiple devices which can be independently copied, altered or seized by an attacker. Thus, potential users need to carefully evaluate which of the AEM setup options are most suited for their particular threat model, if any.

Deliverables (applicable to both primary and stretch goals):

  • AEM packages with listed features implemented
  • documentation for enrolling and upgrading users

GitHub issues (tracked in qubes-issues repository) affected by this project:

Implementation

Since Qubes OS aims to be "a reasonably secure operating system" with an emphasis on being user friendly, the primary goal implementation aims to deliver the best possible UX for users whose threat model does not include high enough probability of multistage evil maid attacks. The workflow shall be as follows:

  1. user inserts their closely guarded AEM boot media containing tboot bootloader, Xen hypervisor, dom0 Linux kernel, initrd and associated configuration along with TPM-sealed and passphrase-protected LUKS key file and makes computer boot from it
  2. measured boot is performed and then, assuming neither the computer firmware nor software has been maliciously modified, the Platform Configuration Register (PCR) values inside the TPM will match the state needed to unseal the LUKS key file
  3. once the LUKS key file is unsealed, user is prompted to enter their passphrase in order to decrypt the LUKS key file
  4. assuming the passphrase supplied by user was able to decrypt the key file, internal computer drive is unlocked and computer continues booting the OS

Workflow of the stretch goal implementation which is able to resist some of the possible multistage evil maid attacks is slightly more involved:

  1. user inserts their closely guarded AEM boot media into the computer and makes computer boot from it
  2. bootloader performs a measured boot, attempts to unseal TOTP seed using TPM and, if successful, displays a derived six digit code
  3. user checks whether displayed TOTP code matches the one computed by their 2FA device
  4. if and only if the TOTP codes match, user can safely insert secondary AEM storage media containing the TPM-sealed, passphrase-encrypted LUKS key file
  5. the key file is automatically unsealed by TPM
  6. user is prompted for key file decryption passphrase
  7. assuming correct passphrase was entered and the key file is able to unlock LUKS-protected internal disk, the OS continues booting

In both cases, an attacker observing both screen and keyboard during early boot cannot mount and evil maid attack without either:

  • breaking the measured boot via a vulnerability in Intel TXT, TPM or another vital part of the trusted boot process
  • copying or seizing the AEM boot media and the LUKS key file (possibly stored on separate media), enabling the attacker to access encrypted computer contents upon seizing it

Applicable to the stretch goal implementation only, following additional attack is possible:

  • gaining access to or modifying the TOTP seed, changing time and/or date of the 2FA device or replacing the whole device, allowing exfiltration of AEM boot media contents and LUKS key file, thus enabling the attacker to seize the computer and access its encrypted contents

If using TOTP tokens, user should take care to first memorize the code shown on the computer and only then take out their 2FA device. This avoids a possible attack whereas an attacker is able to remotely alter computer screen contents in (near) real time.

Please note that AEM protection must be installed on removable media in all cases as observation attacks would capture the TPM Storage Root Key (SRK) passphrase and make it trivial for an attacker to unseal the LUKS key file, should they come to possess it. Combined with observing the passphrase used for the key file, the attacker will be able to unlock the encrypted storage of the target computer.

Timeline

  • May 30 - June 6 (one week)

    • research
      • generating and enrolling a LUKS key file
      • passphrase-protecting the LUKS key file
      • TPM-sealing of the LUKS key file
    • implement
      • proof of concept (PoC) for generating, enrolling, encrypting and sealing a LUKS key file

  • June 6 - June 13 (one week)

    • integrate
      • merge the above PoC into AEM installer, rebuild the package and test

  • June 13 - June 27 (two weeks)

    • implement
      • PoC for disk unlocking using a TPM-sealed, passphrase-protected LUKS key file
    • research
      • how to integrate the unlocking PoC into Dracut initrd and Plymouth
    • integrate
      • merge the above PoC into AEM, rebuild the package and test
    • evaluation
      • first evaluation starts

  • June 27 - July 4 (one week)

    • implement
      • fallback options
    • evaluation
      • first evaluation ends
    • integrate
      • merge the fallback option changes into AEM package, rebuild and test

  • July 4 - July 11 (one week)

    • document
      • enrollment and upgrade procedures
    • integrate
      • rebuild the AEM package to include documentation

  • July 11 - July 18 (one week)

    • review
      • engage the community in reviewing both the documentation and code
    • test
      • engage the community in testing the implementation
    • fix
      • documentation and implementation bug fixing

  • July 18 - July 24 (six days)

    • implement
      • PoC for generating/importing TOTP seed
      • PoC for transferring generated TOTP seed into 2FA device
      • PoC for TPM-sealing TOTP seed and generating codes

  • July 24 - July 28 (four days)

    • second evaluation period

  • July 28 - August 4 (one week)

    • implement
      • fallback options for TOTP
      • displaying and refreshing the TOTP code on Plymouth boot screen
    • integrate
      • merge the TOTP PoCs into AEM package, rebuild, test

  • August 4 - August 11 (one week)

    • implement
      • support for secondary AEM device holding LUKS key file
    • integrate
      • merge the above support into the AEM package, rebuild, test

  • August 11 - August 21 (10 days)

    • implement
      • fallback options
    • integrate
      • merge fallback options into the AEM package, rebuild, test
    • document
      • enrollment and upgrade steps

  • August 21 onward (after the GSoC work period)

    • review
      • engage community in reviewing documentation and code
    • test
      • engage community in testing the implementation
    • fix
      • documentation and implementation bug fixing

Although currently having a twenty hours per week internship, I am confident I will be able to dedicate another thirty to forty hours per week to GSoC, as that would be roughly equal to my schedule during the school year. However, should this be deemed a concern, I could suspend my internship for the three month GSoC working period. No other commitments scheduled during the relevant time frame.

I will be sending progress updates to the qubes-devel mailing list, plus weekly formal summaries.

About me

Second year undergraduate in Information Security at the Faculty of Electrical Engineering and Communication, Brno University of Technology. Previously studied Computer Networks and Communication for two academic years at the Faculty of Informatics, Masaryk University.

Passionate about free and open-source software, computer security and digital privacy. Started coding at the age of twelve, presently focusing on Python.

Almost four years of quality engineering internship at Red Hat. Comfortable working both independently and as part of a team, large code bases are fine, too. Management distance of eight time zones has never been an issue, neither has the fact of not being a native English speaker.

Not submitting GSoC proposal to any other participating organization.

Living in Brno, Czech Republic (UTC+2 / CEST).

Contact information:

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQI5BAEBCAAjBQJY4Q2QHBx4aGFnYXIwMEBzdHVkLmZlZWMudnV0YnIuY3oACgkQ XB5x3wMfmuUUJQ//WlgOlGl3XKNjCk9NtB5A2nz+tEr2Bfdh/ifXAL4Yq+BCQY9H hAOLCbGb7YJb/8Vrp9BG6thkDhwTC9XfYgiDI6nZ/na5LJeNbz0vV91XNr6ePE3n 5M8qAYXiI6d+UMdj3yL+xLVPQns2pLWk6ppK+BjixxuugFfJwclRs9B7ao12Gu9F 2S30aFbuMXJ1MMRCorejngD/n5Fh6yATNU8HqzgEoGNRaAFjerSMB0inaFiYEKmG 4FVCuG9IRLUZOMgvC7ZmctCb4Za7gprjvcC/Np108G/qvtED93jedKv4FjyKJV+w Gv+PFdRsiA2ly1sGH041cuPcb4C8YJxYHV/smdCePobadw+UYkNnEZ5EuQcEBbHM IjU/nKbfCpcmA71czHbBLuPnxcNRmrjShST2thoc4RgjorUoH+zC7SI0AtRIeE1l IxM+3ffX3wDuAc1/1Kd7mgmAUPlQAwQ8JRZTb7szb0N63pOp2oewpD7tR5McQtpS fFuvNC6kERc0kMiKGohJDAbTaGhsRjjW+d3IxhySyM8zzcFRbqojTw0V27GOJg70 mf7ZiBCUwdA0WR7HpjTbUpGzyQ8yWIys4wBH+RNA8/9PeMFrHg/k1LTEbIQM+85N oQFkhRhkM+oHinBIBKagHQbEakOy8ALaiUlV3LE7ZqCYYpajh/n+NIwRsXQ= =vwnl -----END PGP SIGNATURE-----

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment