Skip to content

Physical access attack scenarios and mitigations

Here are gathered various physical attacks scenarios, grouped by method.

Install media image/drive direct tampering

We assume user can have the responsability of generating and keeping at least a single secret to mitigate these attacks.



old school security methods

Attacker is supposed to have undetected one-time access to source install media image or install media image on writable drive before install time or shortly after it.

Any implemented mitigation listed here covers all previous mentioned scenarios.

Base scenario

Unencrypted root file system, no signatures/sums checks.

The simplest possible attack:

  • mount
    • the root file system read write or
    • copy it elsewhere,
  • add the payload
  • then either
    • close the image or
    • regenerate it and replace the old one

Laziest mitigation

  • Perform checksums/signature verifications automatically.
    • upstream archiso (not sure actually)
    • branches of this fork

Same as above, with mitigation implemented

Signatures verifications are functionally equivalent to checksums, since the archiso hook just verifies that the files are correct in relation to provided signature file;

also both the file hashes and the signatures of the files to verify integrity are kept on the same space as the image they need to verify the integrity.

So attack routine is same as before, with an extra step for the attacker to evaluate new hashes and replace signatures with new correct ones from a random new signature.

Laziest mitigation

  • Make root file system signatures untamperable, either
    • by moving them to an encrypted space
      • with secret access token generated at build time (for local user builds of install media images)
        • archiso upstream
        • branches of this fork
      • with secret generated on first run (on publicly distributed install media images)
        • archiso upstream
        • branches of this fork
    • by moving them to a separate device (dongle)
      • archiso upstream
      • branches of this fork

Same as above, with mitigation implemented

Now that attacker can't tamper with root file system because signatures won't correspond and so the archiso hook will block boot, he is forced to tamper with either the kernel or the initramfs.

So he crafts a malicious initramfs or kernel replacing the old one.

Laziest mitigation

  • Add integrity checks at bootloader stage for kernel and initramfs to make them untamperable, too; this can be obtained:
    • by hardcoding sums/fingerprints into bootloader configuration
      • archiso upstream
      • branches of this fork;
    • by loading them or their sums/fingerprints from an encrypted space
      • with secret access token set at build-time (for user local install media images)
        • archiso upstream
        • branches of this fork;
      • with secret access token set on first run
        • archiso upstream
        • branches of this fork;
    • by loading them or their sums/fingerprint from a more secure device (dongle)
      • archiso upstream
      • branches of this fork.

Same as above, with mitigation implemented

Now that the attacker can't tamper with the kernel and the initramfs he is forced to tamper with the bootloader.

So he proceeds to craft a new bootloader binary to re-use one of the above entry points.

Laziest mitigation

  • Move bootloader to a more secure device
    • archiso upstream
    • branches of this fork.

Same as above, with mitigation implemented

Now that the bootloader is untamperable, the attacker is forced to left to tamper with the motherboard firmware.

At this stage is entirely dependent on firmware options at install media drive boot and firmware-level user manual mitigations.

Resources

Edited by Tallero Tallero