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. Si OFW falla en iniciarse correctamente, un procedimiento de recuperación de firmware se intenta - detalles TBD.
2. En lo siguiente, las imágenes "primarias" son los archivos en /boot, y las imágenes "secundarias" son los archivos en /boot-alt, a menos que la tecla de "check" del gamepad sea presionada durante el booteo, en ese caso los roles se reversan: los archivos primarios vienen de /boot-alt, y los archivos secundarios vienen de /boot.
3. OFW chequea una nueva imagen de firmware en el directorio /boot en una USB conectada, luego una SD y aparato (XO). Si existe y verifica, OFW se reflashea el mismo y rebootea.

   Las USB actualizadas pueden contener actualizaciones solo de firmware.

4. OFW busca una nueva imagen de firmware en el directorio primario en la NAND flash. Si una existe y se verifica, OFW se reflashea el mismo y se rebootea.
5. OFW bloquea inscripciones futuras del SPI FLASH con el bloqueo de hardware.
6. Si una clave de desarrollador valida esta presente, OFW entra a un modo no seguro, donde se comporta como corrientemente lo hace. De otra forma ...
7. Si la clave de activación presente es valida (llene los detalles), los nombres de archivo del booteo serán runos.zip y (si esta presente) runrd.zip. De otra forma, los archivos de booteo seran actos.zip y (si están presente) actrd.zip.
8. Si la clave de actualización esta presente y es valida, intentaremos verificar y bootear desde los archivos de booteo en /boot en una USB conectada, luego SD, y aparato (XO).
9. OFW verifica y bootea desde los archivos de boot en el directorio primario.
10. OFW verifica y bootea desde los archivos de boot en el directorio secundario.
11. Si ninguno de los pasos de booteo anteriores es exitoso, OFW muestra una pantalla de error y se para.

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.