[Arm-netbook] Opensouce TPM

Thu Dec 8 17:10:10 GMT 2016

2016-11-23 18:21 GMT+01:00 Denis 'GNUtoo' Carikli <GNUtoo at no-log.org>:

> On Thu, 3 Nov 2016 10:28:22 +0000
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
>
> > On 11/3/16, mike.valk at gmail.com <mike.valk at gmail.com> wrote:
> > > Interesting:
> > > http://phoronix.com/scan.php?page=news_item&px=Google-
> Building-OSS-TPM2
> >
> >  yeah, very.  means they no longer trust third party proprietary TPM
> > implementations, which is in and of itself all we really need to know.
> There isn't only that. You also need to force the hardware to use the
> TPM. ChromeOS probably already does that.
>
> Using an ME to do that is not compatible with freedom.
> When there is no ME, BIOSes and UEFI typically set the bootblock
> read-only and have code in there to start using the TPM.
> Otherwise there is no way to prevent a malicious user to replay a good
> boot to the TPM while a totally different boot software was used.
>
> There are patches for flashrom that are being reviewd AFAIK for adding
> the ability to set flash zones read-only.
> Note that "read-only" can have different meaning:
> - The zone can be forever read-only
> - The zone can be read-only if the write protect pin of the flash is
>   grounded.
> - The zone can be read-only until the next boot or reboot.
>
> On x86 hardware, the chipset can also be programmed to do make zones
> of the boot flash read-only until the next boot.
>
> AFAIK chromeOS uses the flash read-only features to do it, while
> typicall BIOS/UEFI uses the chipset's read-only features or the ME.
>
> >  now let's see if they create an SSD with full firmware source code
> > available.  the first low-cost SoC with on-board RAM, ability to
> > connect to multiple eMMC ICs and a USB3-OTG would do the job.
> They probably don't trust SSD and most storage device either.
>
> Given that:
> - Most storage devices (HDD,SSD,USB keys, SD, microSD, etc) have
>   non-free firmwares.
> - GNU/Linux probably trust storage devices by default. Storage devices
>   could easily detect (by looking at the access pattern) what
>   program/os is accesing a given file. That probably leads to TOCTOU
>   attacks.
> - The boot flash(which has libreboot/coreboot/The BIOS/UEFI/etc) has no
>   firmware so far. As far as I know it's only hardware.
>
> You don't have many options left if you want to avoid such attacks.
> ChromeOS chose to verify the kernel+(initramfs?) from code that is
> running from the boot flash and then to use dm-verity for the
> filesystem.
>

Probably nothing on the open market. EOMA68 comes close. But does not have
tamper protection. It does however give to option to verify every aspect.
Making it tamper protected would make this even harder exercise even more
difficult.

The issue is that we work with complex systems. There is no longer one
single CPU. A lot of parts are timing sensitive and are general purpose,
power management, communication. Even within the SoC. The cheap solution is
to use general purpose microcontrollers are used opposed to build logic
systems from ground up. Building logic systems is expensive and time
consuming. Writing software is fast(er) and cheap(er).

Every microcontroller is a "computer" on it's own. And thus an attack
vector.

Attack vectors for EOMA68-A20 that I see:
1. Microcontrollers in every USB connector. (But that's an vector for all
systems)
2. A20 has a RISC cpu inside for power management purposes. Not used by
currently iirc. But not checked either.
3. The PMIC is an Microcontroller with firmware
4. The housing has a ARM microcontroller. Which runs it's own RTOS.
5. Audio attacks on the sound stack

The list for Intel machines is miles longer though and more profitable.
Which is a large item in assessing the risk

>
> A fully encrypted rootfs (no /boot in clear) is also a possible way to
> workaround such issue. Libreboot (trough GRUB) can support such thing.
>
> At the end of the day it's still a pain because you also need to wory
> about protecting the device at installation time...
>
> I'm working on a script[2] that build an image with the following
> softaware to address the issue:
> - Coreboot
> - SeaBIOS and iPXE
> - GRUB
>

Hi Dennis, you're being a bit too vague here. If I understand correctly you
are trying to build a installation verification tool?

>
> It fetches a GNU/Linux distribution kernel and initramfs (used in
> netinstall images) in the computer RAM and then computes the checksums.
> It's then up to the user to boot the images or not, to verify that
> the checksums are the ones expected.
>
> So far I've been able to bootstrap debian from it but I've still some
> issues to fix:
> - Debian is not FSDG compliant. Parabola and Trisquel don't publish
>   kenrel+initramfs images for the installer. I should ask them.
> - Installing a fully encrypted rootfs without /boot in clear doesn't
>   seem to be supported in the netinstall, so you need to do some crazy
>   hacks to workaround that.
> - Installing parabola from that debian install is also not very
>   convenient as you need to download,verify and chroot inside the
>   liveCD.
> - I've some issues with the default framebuffer driver used in debian
>   on the Lenovo X60.
>
> On typical SBC things are even worse if you have no other choice than
> booting from the uSD.
>
> However the EOMA68 has a NAND flash, which AFAIK has no firmware.
> I don't know the boot order on it[1]. Having a recovery parabola
> installer there might be a good idea since one can then *very easily*
> pacstrap to another (fully encrypted) storage device.
>
> References:
> -----------
> [1]https://linux-sunxi.org/BROM has some generic information. Using
>    NAND with an SD/microSD card wired as MMC2 seem safe, but I don't
>    know if the uSD is MMC0 or MMC2 in the EOMA.
>

Check the schematics I'd say ;-)

IIRC the flash controller is hardware and controlled from Linux. With eMMC,
which is not used, There is a microcontroller controlling flash much like
SSD's

> [2]The script will be pushed at
>    https://framagit.org/GNUtoo/coreboot-os-installer
>    The commits need to be cleaned up, so the history might be rewritten
>    at some point.
>
> Denis.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20161208/d7b5d6c0/attachment.html>