Firmware Security/lang-es: Difference between revisions
Jump to navigation
Jump to search
RafaelOrtiz (talk | contribs) m (+paragraph) |
RafaelOrtiz (talk | contribs) m (+paragraph) |
||
Line 123: | Line 123: | ||
== Notas de Uso == |
== 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: |
|||
*# Añadir un link /boot/runrd.zip para que si rebooteamos en el primario podamos cambiar hacia /fsroot, o |
|||
*# 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. |
|||
{{ Translated text | |
{{ Translated text | |
||
Line 131: | Line 137: | ||
*# 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. |
*# 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. |
* 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. |
||
| display = |
| display = none }} |
||
{{anchor|Notes}} |
{{anchor|Notes}} |
||
== Notas == |
== Notas == |
||
Revision as of 23:59, 21 July 2007
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 ... |
![]() |
Enfoque
Esta pagina describe el rol de Open Firmware en la seguridad BitFrost en el XO
Objetivos
- Correr el Firmware de recuperacion si el firmware primario esta mal.
- No acceso a el ok prompt sin clave de desarrollador
- Las imagenes de actualizacion de Firmware deben estar firmadas
- Las imagenes de booteo deben estar firmadas
- Laptops sin activar solo bootearan la imagen de activacion
- Bootear una imagen de SO aternativa si laprimaria esta dañada
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.
Proceso
- Si OFW falla en iniciarse correctamente, un procedimiento de recuperación de firmware se intenta - detalles TBD.
- 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.
- 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.
- 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.
- OFW bloquea inscripciones futuras del SPI FLASH con el bloqueo de hardware.
- 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 ...
- 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.
- 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).
- OFW verifica y bootea desde los archivos de boot en el directorio primario.
- OFW verifica y bootea desde los archivos de boot en el directorio secundario.
- Si ninguno de los pasos de booteo anteriores es exitoso, OFW muestra una pantalla de error y se para.
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:
- Añadir un link /boot/runrd.zip para que si rebooteamos en el primario podamos cambiar hacia /fsroot, o
- 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.
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.