Firmware Security/lang-es: Difference between revisions
Jump to navigation
Jump to search
RafaelOrtiz (talk | contribs) m (+paragraph) |
m (spelling) |
||
(7 intermediate revisions by 4 users not shown) | |||
Line 8: | Line 8: | ||
== Enfoque == |
== Enfoque == |
||
Esta pagina describe el rol de [[Open Firmware/lang-es|Open Firmware]] en la seguridad [[OLPC Bitfrost/lang-es| |
Esta pagina describe el rol de [[Open Firmware/lang-es|Open Firmware]] en la seguridad [[OLPC Bitfrost/lang-es|Bitfrost]] en el XO |
||
{{ Translated text | |
{{ Translated text | |
||
This page describes the role of [[Open Firmware]] in [[OLPC Bitfrost| |
This page describes the role of [[Open Firmware]] in [[OLPC Bitfrost|Bitfrost]] security on XO. |
||
| display = none }} |
| display = none }} |
||
Line 16: | Line 16: | ||
== Objetivos == |
== Objetivos == |
||
# Correr el Firmware de |
# Correr el Firmware de recuperación si el firmware primario esta mal. |
||
# No acceso a el ok prompt sin clave de desarrollador |
# No acceso a el ok prompt sin clave de desarrollador |
||
# Las |
# Las imágenes de actualización de Firmware deben estar firmadas |
||
# Las |
# Las imágenes de booteo deben estar firmadas |
||
# Laptops sin activar solo bootearan la imagen de |
# Laptops sin activar solo bootearan la imagen de activación |
||
# Bootear una imagen de SO |
# Bootear una imagen de SO alternativa si la primaria esta dañada |
||
{{ Translated text | |
{{ Translated text | |
||
# Run recovery firmware if primary firmware is bad |
# Run recovery firmware if primary firmware is bad |
||
Line 34: | Line 34: | ||
== Archivos == |
== Archivos == |
||
Los archivos listados abajo |
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 |
* 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 |
*: ''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 clave de activacion es llamada "/security/activate.key". |
||
*: ''la version 1 del formato de la clave es una lista json descrita por [http://dev.laptop.org/git?p=users/krstic/leases;a=blob;f=bitfrost/activation.py activation.py in the leases package]'' |
*: ''la version 1 del formato de la clave es una lista json descrita por [http://dev.laptop.org/git?p=users/krstic/leases;a=blob;f=bitfrost/activation.py activation.py in the leases package]'' |
||
*: El timestamp de |
*: El timestamp de expiración es [http://en.wikipedia.org/wiki/ISO_8601 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". |
* La clave del desarrollador es llamada "/security/develop.key". |
||
*: ''Rationale: El directorio /security se deja sin tocar por el proceso de |
*: ''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 |
* 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.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) |
** os.key es la firma ASN.1 de la os.img como se define por el bios_crypto (SHA256->ECC256) |
||
Line 49: | Line 49: | ||
** rd.key es la firma ASN.1 de la rd.img como se deine por el bios_crypto (SHA256->ECC256) |
** 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. |
** 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 |
**: ''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" |
* 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.img es el formato usual de imagen para OFW |
||
Line 57: | Line 57: | ||
En un disco USB disk o tarjeta SD, los archivos son los siguientes: |
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). |
* 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 |
*: ''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 |
*: ''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.'' |
||
{{ Translated text | |
{{ Translated text | |
||
Line 91: | Line 91: | ||
== Proceso == |
== Proceso == |
||
# Si OFW falla en iniciarse correctamente, un procedimiento de recuperación de firmware se intenta - detalles TBD. |
# 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 " |
# 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. |
||
# 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. |
# 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.'' |
#: ''Las USB actualizadas pueden contener actualizaciones solo de firmware.'' |
||
Line 142: | Line 142: | ||
== Notas == |
== 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. |
|||
{{ Translated text | |
{{ Translated text | |
||
Line 148: | Line 152: | ||
* 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. |
* 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. |
* Firmware RTC *must be UTC*. Quanta must set the RTC to UTC at the factory; antitheft server must sync to UTC during antitheft interaction. |
||
| display = |
| display = none }} |
||
Latest revision as of 16:15, 1 June 2012
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 recuperación si el firmware primario esta mal.
- No acceso a el ok prompt sin clave de desarrollador
- Las imágenes de actualización de Firmware deben estar firmadas
- Las imágenes de booteo deben estar firmadas
- Laptops sin activar solo bootearan la imagen de activación
- Bootear una imagen de SO alternativa si la primaria esta dañada
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.
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 "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.
- 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
- 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.