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 recuperación si el firmware primario esta mal.
2. No acceso a el ok prompt sin clave de desarrollador
3. Las imágenes de actualización de Firmware deben estar firmadas
4. Las imágenes de booteo deben estar firmadas
5. Laptops sin activar solo bootearan la imagen de activación
6. Bootear una imagen de SO alternativa si la primaria 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 están en el NAND FLASH en JFFS2. Los archivos zip listados deben ser creados sin compresión (opción -n) y sin paths (opción -j). Las notas de implementación y racionale están en itálica.

• Las imágenes primarias están en /boot, las imágenes secundarias están en /boot-alt

  Al comienzo de proceso de upgrade, boot se copia a boot-alt; esto no necesita ser atómico. cuando el upgrade es completo y valido, los archivos actualizados sean movidos atómicamente hacia /boot. La sustitución atómica requiere que /boot sea un link simbólico del directorio de boot 'real', que estará en /boot-XXXXXX, donde las X's son escogidas por mkdtemp con el fin de que sean únicas.

• 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 expiración es ISO 8601 UTC datetime en formato básico (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 actualización.

• 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 activación 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 activación y en ciertos upgrades. Como una optimización, podemos saltar la autenticación y la carga del ramdisk cuando no se necesite para simplificar y hacer mas veloz el booteo. En la practica runrd.zip es un symlink que puede ser fácilmente 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 razón, debe haber siempre un ramdisk, pero puede ser monolítico 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 después de que hayan sido cargados en la memoria, para prvenir ataques que involucren cambios de archivos entre autenticación 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 "O" 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

• Despues del booteo, el usuario puede determinar la fuente desde el arbl de aparato de OFW en /ofw/<fill me in>. Esto puede ser usado para determinar si la activación es necesaria (actos.zip) o si el booteo esta siendo desarrollado desde la fuente secundaria (boot-alt/*).
• Aunque afuera del enfoque de esta especificación hay raices de sistemas de ficheros secundaria y primaria en /fsroot y /fsroot-alt correspondiendo a los kernels en /boot y /boot-alt. /boot/runrd.img estará típicamente ausente para acelerar el boot. sin embargo, /boot-alt/runrd.img típicamente sera necesaria para cambiar hacia /fsroot-alt para que el kernel y el campo del usuario estén de acuerdo. Cuando clonamos /boot en /boot-alt al principio de una actualización, hacemos una conexión apropiada hacia /boot-alt/runrd.img.
• Cuando el kernel alternativo ha sido cargado y hemos cambiado hacia /fsroot-alt, podemos hacer cualquiera de lo siguiente:
  1. Añadir un link /boot/runrd.zip para que si rebooteamos en el primario podamos cambiar hacia /fsroot, o
  2. Intercambiar /boot y /boot-alt, haciendo que futuros booteos empiecen con este kernel. Esta opción es preferible. Debemos asegurar que hemos hecho otro upgrade antes de intentar bootear en un kernel diferente de nuevo.
• Típicamente usaremos enlaces duros o suaves para evitar guardar múltiples SO e imágenes de ramdisk. El actual plan es actualmente tener solo un kernel y una imagen de ramdisk; El ramdisk mirara como fue llamado para determinar si este es un upgrade, activación o booteo alternativo.

• 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

• Estoy asumiendo que el uso principal del booteo USB/SD es para hacer actualización de OS, firmware, o actividades donde le ancho de banda es la limitación. Esto puede ser fácilmente hecho con el mecanismo dado por solo poniendo una "magic upgrade key" (propiamente firmada) en el puerto USB y hacer un ciclo de apagado.
• Las pruebas de USB consumen tiempo y son peligrosas (aunque SD no lo es). En algún punto (después de que los procesos de manufacturan hayn sido arreglados) Solo intentaremos bootear desde una USB si la tecla 'X' de juego es presionada durante el booteo.
• podemos ser mas user-friendly detectando la "failed boot after linux kernel invocation" de alguna forma, y bootear automáticamente desde el backup en este caso. Esto parece un trabajo post-FRS.
• Firmware RTC *debe ser UTC*. Quanta debe poner el RTC en UTC en la fabrica; el servidor antirobo debe sincronizarse a UTC durante la interacción antirobo.

• 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.