Re:Linux workstation security checklist
by nickpsecurity on Friday August 28, 2015 @11:49AM
(#10136101)
I agree with you. I had to design some concepts for securing a boot process or replacing BIOS. My first inspirations were Open Firmware, Coreboot, and U-Boot, already doing much of the job. However, all too complicated, incomplete, or Forthy. So, I saw it from three basic angles drawing on what was done in past:
1. Replaceable ROM or read-only, flash chip that the system booted from with open-spec for user customization. You can trust their bootloader, yours, etc. Modifications require physical replacement to avoid software attacks. You can know what it's doing because you can flash it yourself or use your own if it's physically compatible. Can be cheap. Simple.
2. Combination of anti-fuse ROM and flash. The ROM has a highly robust firmware that test chip, initializes some stuff, pulls firmware out of flash, does crypto checks on it, and then runs it. In a maintenance or update mode, the ROM + flash combo can pull up an upgrade into memory, disable all I/O that can affect it, check it, flash it into storage, and reboot. ROM can't be modified without physical replacement, so always a root of trust to start with. Can be combined with No 1 if necessary.
3. Software-only protection necessitates combating 0-days. This means gotta use an EAL6+ development process. Abstract away hardware details into functions with interface types and checks. Code in safe subset with static analysis, testing, and simulation. Make different device handling pluggable modules to run that interact with safe interface. Extract implementation from that. Examples include using SPARK Ada, MISRA C w/ ASTREE checker, or Java via BootSafe technology. Optionally auto-gen tech like Termite for drivers.
Personally, I think we could go with No 1 on everything down to laptops and some tablets. Ultra-compact things such as smartphones can use No 2. No 3 is only for the most stubborn, cost-sensitive companies and those are unfortunately least likely to go the extra mile lol.
1. Replaceable ROM or read-only, flash chip that the system booted from with open-spec for user customization. You can trust their bootloader, yours, etc. Modifications require physical replacement to avoid software attacks. You can know what it's doing because you can flash it yourself or use your own if it's physically compatible. Can be cheap. Simple.
2. Combination of anti-fuse ROM and flash. The ROM has a highly robust firmware that test chip, initializes some stuff, pulls firmware out of flash, does crypto checks on it, and then runs it. In a maintenance or update mode, the ROM + flash combo can pull up an upgrade into memory, disable all I/O that can affect it, check it, flash it into storage, and reboot. ROM can't be modified without physical replacement, so always a root of trust to start with. Can be combined with No 1 if necessary.
3. Software-only protection necessitates combating 0-days. This means gotta use an EAL6+ development process. Abstract away hardware details into functions with interface types and checks. Code in safe subset with static analysis, testing, and simulation. Make different device handling pluggable modules to run that interact with safe interface. Extract implementation from that. Examples include using SPARK Ada, MISRA C w/ ASTREE checker, or Java via BootSafe technology. Optionally auto-gen tech like Termite for drivers.
Personally, I think we could go with No 1 on everything down to laptops and some tablets. Ultra-compact things such as smartphones can use No 2. No 3 is only for the most stubborn, cost-sensitive companies and those are unfortunately least likely to go the extra mile lol.