Firmware Security/lang-es

  Esta página está supervisada por el equipo de OLPC.

This is an on-going translation

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

Enfoque

Esta pagina describe el rol de Open Firmware en la seguridad BitFrost en el XO

This page describes the role of Open Firmware in BitFrost security on XO.

Objetivos

1. Correr el Firmware de recuperacion si el firmware primario esta mal.
2. No acceso a el ok prompt sin clave de desarrollador
3. Las imagenes de actualizacion de Firmware deben estar firmadas
4. Las imagenes de booteo deben estar firmadas
5. Laptops sin activar solo bootearan la imagen de activacion
6. Bootear una imagen de SO aternativa si laprimaria esta dañada

1. Run recovery firmware if primary firmware is bad
2. No access to ok prompt without developer key
3. Firmware update images must be signed
4. Boot images must be signed
5. Unactivated laptops will only boot the activation image
6. Boot alternate OS image if primary OS image is bad

Archivos

Los archivos listados abajo estan en el NAND FLASH en JFFS2. Los archivos zip listados deben ser creados sin compression (opcion -n) y sin paths (opcion -j). Las notas de implmentacion y racionale estan en italica.

• Las imagenes primarias estan en /boot, las imagenes secundarias estan en /boot-alt

  Al comienzo de proceso de upgrade, boot se copia a boot-alt; esto no necesita ser atomico. cuando el upgrade ese compleo y validad, los archivos actualizados sean movidos atomicamente hacia /boot. La sustitucion atomica requiere que /boot sea un link simbolico del directorio de boot 'real', que estara en /boot-XXXXXX, donde las X's son escogidas por mkdtemp con el fin de que sean unicas.

• La clave de activacion es llamada "/security/activate.key".

  la version 1 del formato de la clave es una lista json descrita por activation.py in the leases package

  El timestamp de expiracion es ISO 8601 UTC datetime en formato basico (no dashes o colons) sin segundos fraccionales. Por ejemplo: 20070713T113600Z

• La clave del desarrollador es llamada "/security/develop.key".

  Rationale: El directorio /security se deja sin tocar por el proceso de actualizacion.

• La imagen de SO normal esta en "/boot/runos.zip", conteniendo "os.img" y "os.key", y "/boot/runrd.zip", conteniendo "rd.img" y "rd.key". Una imagen de SO de activacion esta en "/boot/actos.zip", conteniendo "os.img" y "os.key", y "/boot/actrd.zip", conteniendo "rd.img" y "rd.key".
  • os.img es uno de los formatos de carga que OFW soporta, e.g. Linux bzImage
  • os.key es la firma ASN.1 de la os.img como se define por el bios_crypto (SHA256->ECC256)
  • rd.img es una imagen ramdisk en un formato soportado por el kernel en la os.img (tipicamente initramfs)
  • rd.key es la firma ASN.1 de la rd.img como se deine por el bios_crypto (SHA256->ECC256)
  • runrd.zip/actrd.zip puede ser omitido, en cuyo caso runos.zip/actos.zip se bootea sin un ramdisk.

    Rationale: El ramdisk es solo usado durante la activacion y en ciertos upgrades. Como una optimizacion, podemos saltar la autentificacion y la carga del ramdisk cuando no se necesite para simplificar y hacer mas veloz el booteo. En la practca runrd.zip es un symlink que puede ser facilmente borrado y recreado cuando se necesite.

• La nueva imagen de firmware es "/boot/bootfw.zip", conteniendo "bootfw.img" y "bootfw.key"
  • bootfw.img es el formato usual de imagen para OFW
  • bootfw.key es una firma ASN.1 como se define por el bios_crypto (Whirl->RSA, SHA512->RSA, Whirl->ECC521, SHA512->ECC521)
• Los archivos de backup en /boot-alt tienen los mismos nombres y tienen los mismos formatos que en /boot.

En un disco USB disk o tarjeta SD, los archivos son los siguientes:

• Solo un directorio, /boot, conteniendo runos.zip, bootfw.zip, y un runrd.zip opcional (como antes).

  La seguridad dicta que booteamos de un sistema de archivos autentificado. En vez de hacer que OFW autentifique los contenidos completos de USB/SD, bootearemos de un ramdisk autentificado, que puede autenticar cualquier archivo que necesite (si alguno) de los discos USB/SD. Por esta razon, debe haber siempre un ramdisk, pero puede ser monoloitico con el kernel, en runos.zip en vez de en un archivo runrd.zip separado.

  Debemos ser cuidadosos para asegurar que los archivos sean autenticados despues de que hayan sido cargados en la memoria, para prvenir ataques que involucren cambios de archivos entre autenticacion y uso posterior de estos.

{{{1}}}

Proceso

1. If OFW fails to come up correctly, a firmware recovery procedure is attempted - details TBD.
2. In the following, the "primary" images are the files in /boot, and the "secondary" images are the files in /boot-alt, unless the "check" gamepad key is held down during boot, in which case the roles reverse: the primary files come from /boot-alt, and the secondary files come from /boot.
3. OFW checks for a new firmware image in the /boot directory on an attached USB, then SD, device. If one exists and verifies, OFW reflashes itself and reboots.

   Upgrade USB keys may contain firmware-only upgrades.

4. OFW checks for a new firmware image in the primary directory in the NAND flash. If one exists and verifies, OFW reflashes itself and reboots.
5. OFW locks out further SPI FLASH writing with the hardware lock.
6. If a valid developer key is present, OFW enters non-secure mode, where it behaves as it currently does. Otherwise ...
7. If the activation key is present and valid (fill in details), the boot filenames will be runos.zip and (if present) runrd.zip. Otherwise, the boot filenames will be actos.zip and (if present) actrd.zip.
8. If the activation key is present and valid, we will attempt to verify and boot from the boot files in /boot on an attached USB, then SD, device.
9. OFW verifies and boots from the boot files in the primary directory.
10. OFW verifies and boots from the boot files in the secondary directory.
11. If none of the above booting steps succeed, OFW displays and error screen and halts.

Notas de Uso

• After boot, userland can determine the source source from the OFW device tree in /ofw/<fill me in>. This can be used to determine whether activation is needed (actos.zip) or whether booting is being performed from the secondary source (boot-alt/*).
• Although outside the scope of this spec, there are primary and secondary filesystem roots in /fsroot and /fsroot-alt corresponding to the kernels in /boot and /boot-alt. /boot/runrd.img will typically be absent to speed boot. However, /boot-alt/runrd.img will typically be required in order to switch to /fsroot-alt so that kernel and userland match. When we clone /boot into /boot-alt at the beginning of an upgrade, we link in an appropriate /boot-alt/runrd.img
• When the alternate kernel is booted and we've switched into /fsroot-alt, we can either:
  1. add a /boot/runrd.zip link so that if we reboot into the primary we can switch the filesystem back /fsroot, or
  2. Swap /boot and /boot-alt, making future boots start this kernel. This option is preferred. We should ensure that we've done another upgrade before we try to boot into a different kernel again.
• We will typically use hard or soft links to avoid storing multiple os and ramdisk images. The current plan is to actually have only one kernel and one ramdisk image; the ramdisk will look at how it was invoked to determine whether this is an upgrade, activation, or alternate boot.

Notas

• I am assuming that the primary use of USB/SD boot is to do OS, firmware, or activity upgrades where bandwidth is a limitation. These can easily be done with the mechanism provided by just sticking a (properly signed) "magic upgrade key" into the USB port and power-cycling.
• USB probing is time-consuming and perilous (although SD is not). At some point (after manufacturing processes are fixed) we'll only try to boot from USB if the 'X' game key is pressed during boot.
• We could be more user-friendly by detecting "failed boot after linux kernel invocation" in some way, and automatically booting from the backup in this case. This seems like post-FRS work.
• Firmware RTC *must be UTC*. Quanta must set the RTC to UTC at the factory; antitheft server must sync to UTC during antitheft interaction.