OS Image Digestor/lang-es: Difference between revisions
(intermediate translation) |
m (revert previous minor edit) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Image:deerislandeggs.jpg|300px|thumb|right| |
[[Image:deerislandeggs.jpg|300px|thumb|right|Cyclistas visitando digestores "huevo" en Deer Island, Boston, Massachusetts]] |
||
El OS Image Digestor es una shellscript corta que se puede usar para crear [[OFW NAND FLASH Updater|OFW Placement Control Files |
El OS Image Digestor es una shellscript corta que se puede usar para crear [[OFW NAND FLASH Updater|archivos de control de colocación]] (ingl. OFW Placement Control Files, un archivo que contiene una lista de sumas de verificacion del imagen), que son usados por [[OpenFirmware]] durante los procesos reflashear el sistema. En vez de enviar éstos archivos a la oficina de OLPC principal, es posible para los despligues hacer imagenes del SO personalizadas que se pueden ser usadas en el [[Secure reflash|processo de reflashear con seguridad]] sin requerir que OLPC tenga que manejar las imagenes de sistemas directamente. Este elimina un punto de latencia crítica (el tiempo requerido para enviar imagenes en total a través de enlances lentos) en el desarollo de imagenes personalizadas que se pueden usar en el proceso de reflashear bajo el sistema de seguridad. |
||
== OLPC OS Image Digestor == |
== OLPC OS Image Digestor == |
||
| Line 9: | Line 9: | ||
git clone git://dev.laptop.org/users/erik/image-digestor |
git clone git://dev.laptop.org/users/erik/image-digestor |
||
=== Objectivo === |
=== Objectivo === |
||
Simplificar el proceso de producir una imagen de SO usable en el proceso de reflashear con seguridad. Dar un metodo de compartir solamente los datos de una imagen de SO que son importantes en el proceso de firmar una imagen para uso en el proceso de reflashear |
Simplificar el proceso de producir una imagen de SO usable en el proceso de reflashear con seguridad. Dar un metodo de compartir solamente los datos de una imagen de SO que son importantes en el proceso de firmar una imagen para uso en el proceso de reflashear en una XO con seguridad habilitado. |
||
=== |
=== Resumen === |
||
[[Secure reflash|Reflashear con el sistema de seguridad habilitado]] (ingl. "secure reflash") es el proceso de copiar una imagen firmada del sistema operativo sobre una laptop. En este proceso se necesita un archivo como se llama 'fs.zip' que contiene un archivo de control de colocación y un archivo que contiene una firma sobre el archivo de control de colocación y una clave criptográfico privado de OLPC. Durante el proceso de actualizacion, OFW lee estos archivos y verifica que la firma concide con el archivo de control de colocación. Si cambia algo en la cadena entre la firma, el archivo de colocación control, y la imagen del SO, OFW no continua con el proceso de actualizacion. Este cadena comprisa el [[OLPC_Bitfrost#P_NAND_RL:_NAND_write.2Ferase_protection|cerradura de reflashear]] que [[Bitfrost]] define. |
|||
[[Secure reflash]] is the process of copying a system image onto a laptop with the |
|||
OLPC security system enabled. The scripts in this repository can be used to |
|||
create [[OpenFirmware]] (OFW) update scripts from images which are destined for use |
|||
during the secure reflash of OLPC XO laptops. These scripts are signed using |
|||
OLPC infrastructure to produce a file (fs.zip) which must be included alongside |
|||
any OS image during the secure reflash process. |
|||
Se puede usar las scriptes en este repositorio para generar archivos de control de colocación de imagenes personalizadas. Estes archivos podrian ser firmada por la infrastructura de seguridad de OLPC para hacer el fs.zip que se necesita para actualizar con el sistema de seguridad habilitado. |
|||
=== |
=== Uso === |
||
Usando un [[OS_images|imagen de SO]] para la XO que contiene un sistema de archivos jffs2: |
|||
filesystem: |
|||
$ ./image-digestor.sh < |
$ ./image-digestor.sh <nombre_de_imagen> |
||
Este produce <nombre_de_imagen_basada>.plc. Para uso en el proceso de reflashear con el sistema de seguridad habiltado, el script (*.plc) resultante se debe estar como data.img en un archivo fs.zip firmada por OLPC. Actualamente este requiere contacto con la oficina de OLPC principal. |
|||
This produces <image_file_name>.ofw_update_script. For use in secure reflash, |
|||
the resulting update script must be included as data.img in an OLPC-signed |
|||
fs.zip. At present this requires contact with OLPC's main office. |
|||
=== Requisitos === |
|||
The common Linux utilities dd and sha256sum are required. These are present in |
|||
the 'coreutils' package in Fedora, Ubuntu, and Debian, so this should be no |
|||
issue on most systems. |
|||
Los programas Linux comúnes dd y sha256sum son requisitos. Estos estan parte de paquete 'coreutils' en Fedor, Ubuntu, y Debian, y no sea problema en la mayoria parte de sistemas Linux. |
|||
=== |
=== Información antecedentes === |
||
* [[OFW NAND FLASH Updater|OFW |
* [[OFW NAND FLASH Updater|OFW archivo de control de colocación]] |
||
Una script de actualizacion, la mayoria parte de que es una lista de los sha256sums (sumas de verificacion) para cada bloque de borrar (ingl. erase block, una parte de 128KiB de la memoría de la flash) de la imagen de SO ser flasheada. Durante el proceso de actualizacion OFW usa estes sumas para verificar la validad de cada bloque como esta copiada en la memoría interna de la XO. |
|||
A reflash script, the bulk of which is a list of sha256sums (digests) for each |
|||
erase block (128KiB chunk) of the image to be flashed. During the update |
|||
process OFW uses the shasums to check the validity of each block as it is |
|||
copied onto the internal memory (NAND flash) of the XO. |
|||
* [[Secure reflash| |
* [[Secure reflash|Reflashear con seguridad]] |
||
Reflashear con seguridad requiere que la script de control de colocación ser firmada con una clave criptográfico privado de OLPC. El archivo resultante (una firma criptográfico) esta localizado con la script de control de colocación y un archivo que significa la version de build (version.txt) en el archivo fs.zip. Este archivo se pone con el archivo de imagen de SO en una memoria USB para uso en el proceso de actualización. Cuando se empieza el proceso de actualizar, OFW lee estes archivos y los compara la firma con la clave criptográfico de OLPC publico que esta en el firmware. OFW solamente continua con la actualización si este firma acorda con la clave publico, y los sumas de verificacion acordan con la imagen. |
|||
Secure reflash requires that the OFW update script be signed with a secure |
|||
private key. The results are stored in a file called fs.zip, which contains the |
|||
update script (data.img), a signature dependent on OLPC's private key and the |
|||
update script (data.sig), and a file indicating the build version name |
|||
(version.txt). This file is then placed alongside the image to be flashed on |
|||
USB flash media, and is read during the reflash process to validate the build. |
|||
The firmware only continues with the reflash if the signature file matches the |
|||
update script. |
|||
Nota que los sistemas de seguridad importantes durante el booteo son independientes de el sistema de actualizacion. En una XO con el sistema de seguridad habilitado, medidas distintas occuren al prender para verificar que el kernel y initramfs son validos. El booteo va a continuar a condición de que el SO en la XO contiene los firmas del kernel (/boot/runos.zip) y initramfs (/boot/runrd.zip). |
|||
Note that post-boot security is independent from the secure reflash system. On a |
|||
security-enabled XO, separate checks occur at boot to verify that the kernel and |
|||
initramfs are valid. Boot will proceed provided the image which has been built |
|||
contains both the kernel and initramfs signatures (/boot/{runos.zip,runrd.zip}). |
|||
Se puede encontrar documentación del sistema de seguridad de firmware en la XO en [[Firmware security]]. |
|||
Further documentation of firmware-level security systems on the XO can be found |
|||
at [[Firmware security]]. |
|||
Latest revision as of 03:15, 18 December 2008
El OS Image Digestor es una shellscript corta que se puede usar para crear archivos de control de colocación (ingl. OFW Placement Control Files, un archivo que contiene una lista de sumas de verificacion del imagen), que son usados por OpenFirmware durante los procesos reflashear el sistema. En vez de enviar éstos archivos a la oficina de OLPC principal, es posible para los despligues hacer imagenes del SO personalizadas que se pueden ser usadas en el processo de reflashear con seguridad sin requerir que OLPC tenga que manejar las imagenes de sistemas directamente. Este elimina un punto de latencia crítica (el tiempo requerido para enviar imagenes en total a través de enlances lentos) en el desarollo de imagenes personalizadas que se pueden usar en el proceso de reflashear bajo el sistema de seguridad.
OLPC OS Image Digestor
- mantenador: Erik Garrison <erik@laptop.org>
- repositorio: [1]
git clone git://dev.laptop.org/users/erik/image-digestor
Objectivo
Simplificar el proceso de producir una imagen de SO usable en el proceso de reflashear con seguridad. Dar un metodo de compartir solamente los datos de una imagen de SO que son importantes en el proceso de firmar una imagen para uso en el proceso de reflashear en una XO con seguridad habilitado.
Resumen
Reflashear con el sistema de seguridad habilitado (ingl. "secure reflash") es el proceso de copiar una imagen firmada del sistema operativo sobre una laptop. En este proceso se necesita un archivo como se llama 'fs.zip' que contiene un archivo de control de colocación y un archivo que contiene una firma sobre el archivo de control de colocación y una clave criptográfico privado de OLPC. Durante el proceso de actualizacion, OFW lee estos archivos y verifica que la firma concide con el archivo de control de colocación. Si cambia algo en la cadena entre la firma, el archivo de colocación control, y la imagen del SO, OFW no continua con el proceso de actualizacion. Este cadena comprisa el cerradura de reflashear que Bitfrost define.
Se puede usar las scriptes en este repositorio para generar archivos de control de colocación de imagenes personalizadas. Estes archivos podrian ser firmada por la infrastructura de seguridad de OLPC para hacer el fs.zip que se necesita para actualizar con el sistema de seguridad habilitado.
Uso
Usando un imagen de SO para la XO que contiene un sistema de archivos jffs2:
$ ./image-digestor.sh <nombre_de_imagen>
Este produce <nombre_de_imagen_basada>.plc. Para uso en el proceso de reflashear con el sistema de seguridad habiltado, el script (*.plc) resultante se debe estar como data.img en un archivo fs.zip firmada por OLPC. Actualamente este requiere contacto con la oficina de OLPC principal.
Requisitos
Los programas Linux comúnes dd y sha256sum son requisitos. Estos estan parte de paquete 'coreutils' en Fedor, Ubuntu, y Debian, y no sea problema en la mayoria parte de sistemas Linux.
Información antecedentes
Una script de actualizacion, la mayoria parte de que es una lista de los sha256sums (sumas de verificacion) para cada bloque de borrar (ingl. erase block, una parte de 128KiB de la memoría de la flash) de la imagen de SO ser flasheada. Durante el proceso de actualizacion OFW usa estes sumas para verificar la validad de cada bloque como esta copiada en la memoría interna de la XO.
Reflashear con seguridad requiere que la script de control de colocación ser firmada con una clave criptográfico privado de OLPC. El archivo resultante (una firma criptográfico) esta localizado con la script de control de colocación y un archivo que significa la version de build (version.txt) en el archivo fs.zip. Este archivo se pone con el archivo de imagen de SO en una memoria USB para uso en el proceso de actualización. Cuando se empieza el proceso de actualizar, OFW lee estes archivos y los compara la firma con la clave criptográfico de OLPC publico que esta en el firmware. OFW solamente continua con la actualización si este firma acorda con la clave publico, y los sumas de verificacion acordan con la imagen.
Nota que los sistemas de seguridad importantes durante el booteo son independientes de el sistema de actualizacion. En una XO con el sistema de seguridad habilitado, medidas distintas occuren al prender para verificar que el kernel y initramfs son validos. El booteo va a continuar a condición de que el SO en la XO contiene los firmas del kernel (/boot/runos.zip) y initramfs (/boot/runrd.zip).
Se puede encontrar documentación del sistema de seguridad de firmware en la XO en Firmware security.