OLPC Bitfrost/lang-es: Difference between revisions
m (→Daniar la maquina: minor sub-section mistake) |
m (→Daniar la maquina: first draft) |
||
Line 752: | Line 752: | ||
</font> |
</font> |
||
== |
== Dañar la máquina == |
||
<font size="1"> |
|||
526 7.1. Damaging the machine |
526 7.1. Damaging the machine |
||
527 ------------------------- |
527 ------------------------- |
||
528 |
528 |
||
</font> |
|||
El software que desee de algún modo inutilizar la laptop tiene por lo menos cinco vectores de ataque. Puede intentar arruinar la BIOS de la máquina, evitando que arranque. Puede intentar gastar el chip NAND utilizado como almacenamiento primario, que—siendo un chip flash—tiene un número limitado de ciclos de escritura/borrado antes de cesar de operar correctamente y requerir su remplazo. Ataques exitosos a la BIOS o NAND producen daño físico a la máquina, lo que implica que esas laptops requerirán de servicio técnico especializado, incluyendo el remplazo de partes, para su recuperación. El tercer vector, borrado o daño del sistema operativo, es una incomodidad que requerirá que la máquina sea re-espejada (''re-imaged'') y activada para su recuperación. |
|||
<font size="1"> |
|||
529 Software wishing to render a laptop inoperable has at least five attack |
529 Software wishing to render a laptop inoperable has at least five attack |
||
530 vectors. It may try to ruin the machine's BIOS, preventing it from booting. It |
530 vectors. It may try to ruin the machine's BIOS, preventing it from booting. It |
||
Line 766: | Line 771: | ||
537 would require the machine to be re-imaged and reactivated to run. |
537 would require the machine to be re-imaged and reactivated to run. |
||
538 |
538 |
||
</font> |
|||
Dos otros modos de dañar la máquina causan un daño leve: ellos reducen significativamente su utilidad. Estos ataques son degradación de ''performance'' y consumo de batería (con la salvedad que ciertas variantes del primero pueden efectivametne producir el segundo). |
|||
<font size="1"> |
|||
539 Two other means of damaging the machine cause soft damage: they significantly |
539 Two other means of damaging the machine cause soft damage: they significantly |
||
540 reduce its utility. These attacks are performance degradation and battery |
540 reduce its utility. These attacks are performance degradation and battery |
||
Line 771: | Line 780: | ||
542 latter.) |
542 latter.) |
||
543 |
543 |
||
</font> |
|||
Cuando nos referimos a la degradación de ''performance'', nos estamos refiriendo a la sobre-utilizacion de cualquier recurso del sistema como la RAM, la CPU o el chip de red, de modo tal que el sistema se torna lento o que no responda para otros usos. El consumo de la batería puede ser un efecto colateral de dicha degradación maliciosa de la ''performance'' (ej: al evitar las medidas habituales de conservación de energía y la sobre-utilización de dispositivos de hardware glotones energéticos), o pueden ser realizados por algún otro medio. Una vez que se obtengan las mediciones de energía completas de nuestro hardware, estaremos en condiciones de determinar si existen canales alternativos para el consumo de grandes cantidades de energía de la batería sin un impacto en la ''performance'' general; esta sección será actualizada reflejando dicha información. |
|||
<!-- áéíóú ü ñÑ¡¿©® --> |
|||
<font size="1"> |
|||
544 When we say performance degradation, we are referring to the over-utilization of |
544 When we say performance degradation, we are referring to the over-utilization of |
||
545 any system resource such as RAM, the CPU or the networking chip, in a way that |
545 any system resource such as RAM, the CPU or the networking chip, in a way that |
||
Line 783: | Line 797: | ||
554 |
554 |
||
555 |
555 |
||
556 |
556 |
||
</font> |
|||
== Vulnerar la privacidad == |
== Vulnerar la privacidad == |
||
557 7.2. Compromising privacy |
557 7.2. Compromising privacy |
Revision as of 00:32, 1 March 2007
Sistema de seguridad en la laptop XO de la OLPC
La plataforma de seguridad Bitfrost
1 System security on the One Laptop per Child's XO laptop 2 The Bitfrost security platform 3 ======================================================= 4 5 :Author 6 Ivan Krstić 7 ivan AT laptop.org 8 One Laptop Per Child 9 http://laptop.org 10 11 :Acknowledgments 12 Simson Garfinkel, a security consultant for OLPC, contributed to this 13 document. This document also builds upon a growing body known as 14 "HCI-SEC," the application of recent advances in the field of Human 15 Computer Interaction to the important goals of computer security. More 16 information about HCI-SEC can be found in the book "Security and 17 Usability," by Lorrie Cranor and Simson Garfinkel (O'Reilly, 2005), and in 18 Garfinkel's PhD thesis, "Design Principles and Patterns for Computer 19 Systems that are Simultaneously Secure and Usable" (MIT, 2005). 20 21 We acknowledge also a panel of reviewers that prefer to stay anonymous, who 22 provided insightful comments and feedback on previous drafts of this 23 document. 24 25 :Metadata 26 Revision: Draft-19 - release 1 27 Timestamp: Wed Feb 7 00:50:57 UTC 2007 28 Feedback URL: http://mailman.laptop.org/mailman/listinfo/security 29 Authoritative version of this document: http://wiki.laptop.org/go/Bitfrost 30 31 We welcome feedback on this document, preferably to the public OLPC 32 security mailing list, for which you can sign up at the feedback URL given 33 above. If you strongly prefer to keep your comments private, you may mail 34 the author of the document at the provided e-mail address. 35 36 This is NOT the final version of the specification. The contents of this 37 document accurately reflect OLPC's thinking about security at the time of 38 writing, but certain aspects of the security model may change before 39 production. This document will be updated to reflect any such changes. The 40 latest version of this document may be found at the authoritative version 41 URL. 42 43 44 45
Introducción
46 0. Introduction 47 =============== 48
Prefacio
49 0.1. Foreword 50 ------------- 51
En 1971, los programadores Ken Thompson y Dennis Ritchie de AT&T produjeron la primera versión de UNIX. El sistema operativo, que comenzó en 1969 como un proyecto no-pago llamado UNICS, fue renombrado y financiado por Bell Labs cuando los programadores ofrecieron agregarle soporte para el procesamiento de texto. Muchas de esas ideas centrales detrás de Unix aún persisten hoy en día: los populares sistemas operativos para servidores como Linux, FreeBSD, y muchos otros comparten mucho del diseño básico de UNIX.
52 In 1971, 35 years ago, AT&T programmers Ken Thompson and Dennis Ritchie 53 released the first version of UNIX. The operating system, which started in 1969 54 as an unpaid project called UNICS, got a name change and some official funding 55 by Bell Labs when the programmers offered to add text processing support. Many 56 of the big design ideas behind UNIX persist to this day: popular server 57 operating systems like Linux, FreeBSD, and a host of others all share much of 58 the basic UNIX design. 59
La versión de UNIX de 1971 soportaba los siguientes permisos de seguridad en los archivos de usuarios:
- no-dueño puede cambiar el archivo (escritura)
- no-dueño puede leer el archivo
- dueño puede cambiar el archivo (escritura)
- dueño puede leer el archivo
- el archivo puede ser ejecutado
- el archivo es set-uid
60 The 1971 version of UNIX supported the following security permissions on 61 user files: 62 63 * non-owner can change file (write) 64 * non-owner can read file 65 * owner can change file (write) 66 * owner can read file 67 * file can be executed 68 * file is set-uid 69
Estos permisos deben parecerles familiares, ya que son muy similares a los permisos de seguridad que un usuario puede darle a sus archivos hoy en día, en su sistema operativo de elección. Lo que es preocupante—casi increíble—acerca de estos permisos es que han permanecido virtualmente como el único mecanismo de control real que un usuario tiene sobre sus documentos personales actualmente: un usuario puede elegir proteger sus archivos de otras personas en el sistema, pero no tiene ningún control sobre lo que sus programas pueden hacer sobre sus archivos.
70 These permissions should look familiar, because they are very close to the same 71 security permissions a user can set for her files today, in her operating 72 system of choice. What's deeply troubling -- almost unbelievable -- about these 73 permissions is that they've remained virtually the _only_ real control 74 mechanism that a user has over her personal documents today: a user can choose 75 to protect her files from other people on the system, but has no control 76 whatsoever over what her own programs are able to do with her files. 77
En 1971, esto podía ser aceptable: fue 20 años antes del arribo de la Web, y los riesgos para la mayoria de los usuarios era totalmente diferente al que se aplica hoy en día. Pero entonces, como es que nos sorprendemos al no poder detener los virus y malware, cuando nuestras defensas han permanecido básicamente las mismas desde hace 35 años?
78 In 1971, this might have been acceptable: it was 20 years before the advent of 79 the Web, and the threat model for most computer users was entirely different 80 than the one that applies today. But how, then, is it a surprise that we can't 81 stop viruses and malware now, when our defenses have remained largely unchanged 82 from thirty-five years ago? 83
El núcleo del problema radica en el supuesto que cualquier programa ejecutándose en el sistema a cuenta de un usuario debería tener las mismas habilidades y permisos que cualquier otro programa ejecutándose en el sistema a cuenta del mismo usuario. 1971 fue siete años antes que la primera red internacional (basada en packet-switch) existiese. Y la primera red de área amplia (wan - wide area network) usando TCP/IP, el estándar de la actual Internet, no fue creada sino hasta 1983, doce años después que Thompson y Ritchie diseñaran los permisos de archivos que ahora discutimos. En resumidas cuentas, en 1971 casi no existía la posibilidad que un programa "existiera" en una computadora excepto si el dueño de la cuenta—el usuario—lo transportaba físicamente a una máquina (por ejemplo, en cinta perforada), o lo ingresase manualmente. Y por ende, la aproximación a la seguridad del "todo o nada", donde los programas ejecutándose tienen el control total sobre la cuenta de su dueño, tenían sentido: cualquier código que el usuario ejecutáse, gozaba de su confianza ipso-facto en términos prácticos.
84 The crux of the problem lies in the assumption that any program executing on 85 a system on the user's behalf should have the exact same abilities and 86 permissions as any other program executing on behalf of the same user. 1971 was 87 seven years before the first ever international packet-switched network came 88 into existence. And the first wide-area network using TCP/IP, the communication 89 suite used by the modern Internet, wasn't created until 1983, twelve years 90 after Thompson and Ritchie designed the file permissions we're discussing. The 91 bottom line is that in 1971, there was almost no conceivable way a program 92 could "come to exist" on a computer except if the account owner -- the user -- 93 physically transported it to a machine (for instance, on punched tape), or 94 entered it there manually. And so the "all or nothing" security approach, where 95 executing programs have full control over their owner's account, made quite a 96 lot of sense: any code the user executed, she ipso facto trusted for all 97 practical purposes. 98
Avancemos en el tiempo a la actualidad, y la situación no podría ser más diferente: el contraste máximo es quizás la Web, donde el navegador (browser) ejecuta código foráneo en prácticamente todas la páginas visitadas! Los navegadores utilizan mecanismos de areneros (sandbox) cada vez más complejos con la intención de restringir las capacidades para dicho código foráneo (scripts), pero aún los navegadores más modernos están corrigiendo errores en ellos. Y no nos olvidemos del e-mail: cualquiera puede enviarle a un usuario un programa ejecutable, y por muchos años, la reacción casi instintiva era abrirlo y ejecutarlo. El código foráneo no digno de confianza a priori se encuentra por todos lados, y la única defensa pareciera ser un tedioso entrenamiento del usuario y el software anti-virus—suponiendo que este último esté actualizado, y que sus fabricantes hayan tenido el tiempo suficiente para desconstruir cada virus nuevo y construir su correspondiente defensa.
99 Fast forward to today, and the situation couldn't be more different: the 100 starkest contrast is perhaps the Web, where a user's web browser executes 101 untrusted scripting code on just about every web page she visits! Browsers are 102 growing increasingly complex sandboxing systems that try to restrict the 103 abilities of such web scripts, but even the latest browser versions are still 104 fixing bugs in their scripting engine implementations. And don't forget e-mail: 105 anyone can send a user an executable program, and for many years the users' 106 instinctive reaction was to open the attachment and run the program. Untrusted 107 code is everywhere, and the only defense seems to be tedious user training and 108 antivirus software -- the latter assuming it's fully updated, and assuming the 109 antivirus makers have had time to deconstruct each latest virus and construct a 110 defense for it. 111
La mayoría de las ideas y tecnologías que conforman la plataforma Bitfrost no son el resultado de nuevas investigaciones: han sido conocidas en la literatura pertinente durante años, algunas han sido probadas en situaciones reales, y otras en laboratorios. Lo que se destaca en la XO de la OLPC, es que representa la primera vez que estas medidas de seguridad han sido cuidadosamente ensambladas en un sistema a ser distribuido a decenas o centenas de millones de usuarios. Las laptops son probablemente la primvera vez que un producto de computación masiva ha decidido romper con su legado con tal de mejorar la seguridad. Por ejemplo, notarán que la discusión sobre anti-virus y anti-spyware no figura en la especificación de Bitfrost, principalmente porque la plataforma de seguridad torna dicho tema en algo irrelevante.
112 Most technologies and approaches mentioned in the rest of this document do not 113 represent original research: they have been known in the security literature 114 for years, some of them have been deployed in the field, and others are being 115 tested in the lab. What makes the OLPC XO laptops radically different is that 116 they represent the first time that all these security measures have been 117 carefully put together on a system slated to be introduced to tens or hundreds 118 of millions of users. The laptops are also possibly the first time that a 119 mainstream computing product has been willing to give up compatibility with 120 legacy programs in order to achieve strong security. As an example, you'll find 121 that talk about anti-virus and anti-spyware technology is conspicuously absent 122 from this document, because the Bitfrost security platform on the XO laptops 123 largely renders these issues moot. 124
Nos hemos puesto como objetivo crear un sistema que sea drásticamente más seguro y usable que cualquier otro sistema masivo actualmente en el mercado. Un resultado de la dedicación a la usabilidad es que sólo existe una protección provista por Bitfrost que requiere una respuesta del usuario, y aún entonces, es una sencilla pregunta por 'si o no' comprehensible aún por un chico pequeño. El resto de la seguridad es provista tras bambalinas. El llevar al límite los aspectos de usabilidad y seguridad no es fácil, y es importante destacar que no hemos intentado crear, y no creemos que lo hayamos hecho, un sistema "perfectamente seguro". La idea de seguridad perfecta en el mundo real es vana, y negamos todo tipo de insinuacion que lo hayamos logrado.
125 We have set out to create a system that is both drastically more secure and 126 provides drastically more usable security than any mainstream system currently 127 on the market. One result of the dedication to usability is that there is only 128 one protection provided by the Bitfrost platform that requires user response, 129 and even then, it's a simple 'yes or no' question understandable even by young 130 children. The remainder of the security is provided behind the scenes. But 131 pushing the envelope on both security and usability is a tall order, and as we 132 state in the concluding chapter of this document, we have neither tried to 133 create, nor do we believe we have created, a "perfectly secure" system. Notions 134 of perfect security are foolish, and we distance ourselves up front from any 135 such claims. 136 137 138
La Seguridad y la OLPC
139 0.2. Security and OLPC 140 ---------------------- 141
En términos de seguridad, la laptop XO de la OLPC es un ambiente muy particular. Su intención es introducir a chicos pequeños a la computación, muchos en ambientes que no han sido expuestos previamente a la computación o la Internet.
142 In terms of security, the OLPC XO laptops are a highly unique environment. They 143 are slated to introduce computers to young children, many in environments that 144 have had no prior exposure to computing or the Internet. 145
Aún más, la OLPC no tiene como objetivo una distribución reducida donde podría intervenir rápidamente de existir algún problema de seguridad con las máquinas o su uso; en vez, una vez distribuídas, cambios importantes en el modelo de seguridad podrían ser considerados difíciles o imposibles.
146 What's more, OLPC is not targeting small-scale local deployments where it could 147 easily intervene in the case of security problems with the machines or their 148 usage; instead, once the machines are released in the wild, drastic changes in 149 the security model should be considered difficult or impossible. 150
Existe suficiente experiencia en bloquear las máquinas de los usuarios, usualmente en ambientes empresariales o académicos. Pero la OLPC tienen un requisito que invalida la mayor parte del conocimiento común: la OLPC es, por diseño, luchando para ser una plataforma inherentemente maleable, permitiendo a los chicos modificar, adaptar, o "hackear", sus propias máquinas como a ellos les plazca.
151 Plenty of experience exists in locking down user machines, often in corporate 152 or academic settings. But OLPC has a final constraint that invalidates most of 153 the current common wisdom: OLPC is, by design, striving to be an eminently 154 malleable platform, allowing the children to modify, customize, or "hack", 155 their own machines any way they see fit. 156
El resultado es que ninguna política de seguridad sobre la computadora puede satisfacer nuestros requerimientos. En su lugar, distribuiremos y activaremos una politica rigurosa de seguridad apropiada aún al más jóven de los usuarios, y que sea capaz de proveer la máxima seguridad disponible. Sin embargo, proveeremos una interfaz gráfica simple con tal que los usuarios interesados puedan deshabilitar cualquiera de las protecciones, permitiendo al usuario ajustar el nivel de seguridad acorde a su interes en hackear su máquina.
157 As a result, no one security policy on the computer will satisfy our 158 requirements. Instead, we will ship and enable by default a stringent policy 159 that's appropriate even for the youngest user, and which delivers the strongest 160 available protections. However, we will provide a simple graphical interface 161 for interested users to disable any of these protections, allowing the user to 162 tailor the security level to match her interest in hacking her machine. 163
Este modo nos permite ser extremadamente seguros por defecto, y proteger aún al usuario que no tiene ningún concepto de la seguridad digital. Al mismo tiempo, evita el interponerse en el camino del usuario cada vez más sofisticado, e interesado en aumentar sus habilidades con la máquina.
164 This approach allows us to be highly secure by default, and protect even the 165 user who has no conception of digital security. At the same time, it avoids 166 getting in the way of any user who is becoming more sophisticated, and 167 interested in increasing her abilities on the machine. 168
Finalmente, y dado que suscribimos a las teorías de aprendizaje constructivistas, eventualmente queremos incitar a todos los chicos a progresar a un nivel de sofisticación mayor y así tomar mayores libertades con su máquina. Sin embargo, mientras exista el potencial de desastre (ej: tornar la máquina totalmente inoperable, o pérdida total de datos), dicho potencial es un gran obstáculo para el progreso. Y es por eso que además de focalizarse en la seguridad, nos enfocamos explícitamente en proveer mecanismos que logren la recuperación de un modo trivial y no intimidante, como podría ser la recuperación del sistema operativo de múltiples fuentes y copias de respaldo desde un servidor central.
169 Finally, because we subscribe to constructionist learning theories, we want to 170 encourage children to all eventually progress to this level of a more 171 sophisticated user who takes greater liberties with her machine. However, as 172 long as there exists potential for disaster (i.e. rendering a machine fully 173 inoperable, or incurring total data loss), this potential serves as a strong 174 deterrent to this progression. Because of this, in addition to focusing on 175 security by default, we are explicitly focusing on providing mechanisms for 176 trivial and unintimidating disaster recovery, such as operating system recovery 177 from multiple sources and data backup to a central server. 178 179 180
Acerca de este documento
181 0.3. About this document 182 ------------------------ 183
Este documento hace un seguimiento de la seguridad a lo largo del ciclo de vida de la laptop en si, comenzando cuando la laptop es producida en la fábrica, al momento en que llega la chico por primera vez, a lo largo del uso de la laptop por el chico, y finalmente el momento en que el chico se deshace o descarta la laptop. Todo esto es precedido por una breve sección sobre nuestras metas y principios, que sirven como fondo para algunas decisiones que han sido tomadas, y quizás no sean obvias si uno piensa sobre la seguridad en el contexto de una laptop o computadora de escritorio normal.
184 This document follows security throughout the life-cycle of the laptop itself, 185 starting from the moment a laptop is produced in the factory, to the moment it 186 first reaches a child, throughout the child's use of the laptop, and finally 187 stopping at the moment a child wishes to dispose of the laptop. All of this is 188 preceded by a short section on our goals and principles, which serves to 189 provide background to some of the decisions we made, and which might be 190 non-obvious if one thinks of security in the context of normal laptop and 191 desktop machines. 192
Este documento es completo en cuanto lo que se refiere al modelo de seguridad de la OLPC, pero es generalmente no-técnico. Un documento anexo se encuentra en preparación para complementar este con comentarios y descripciones técnicas completas.
193 This document is complete with regard to the OLPC security model, but is 194 generally non-technical. A separate document is being prepared that complements 195 this one with fully technical descriptions and commentary. 196 197 198
Principios y objetivos
199 0.4. Principles and goals 200 ------------------------- 201
Principios
202 === Principles === 203
- Diseño abierto
- La seguridad de la laptop no puede depender de algun diseño secreto implantado en el hardware o software
204 * Open design 205 The laptop's security must not depend upon a secret design implemented in 206 hardware or software. 207
- Sin bloqueos
- A pesar que varios parametros por defecto, el sistema de seguridad de la laptop puede imponer varias prohibiciones a las acciones del usuario, debe existir la manera por la cual éstos sistemas de seguridad puedan ser deshabilitados. En dicho caso, la máquina le permitirá al usuario un control absoluto.
208 * No lockdown 209 Though in their default settings, the laptop's security systems may impose 210 various prohibitions on the user's actions, there must exist a way for these 211 security systems to be disabled. When that is the case, the machine will 212 grant the user complete control. 213
- Sin lecturas requeridas
- La seguridad no puede depender de la habilidad del usuario de leer un mensaje de la computadora y actuar de manera informada y razonable. Si bien el deshabilitar un mecanísmo particular puede requerir una lectura, la máquina debe ser segura desde la fábrica si es entregada a algún usuario que todavía no sabe leer.
214 * No reading required 215 Security cannot depend upon the user's ability to read a message from the 216 computer and act in an informed and sensible manner. While disabling a 217 particular security mechanism _may_ require reading, a machine must be secure 218 out of the factory if given to a user who cannot yet read. 219
- Seguridad que no obstruya
- Siempre que sea posible, la seguridad en las máquinas debe realizarse tras bambalinas, haciendose notar sólamente por medio de sutiles indicadores visuales o audio, y nunca interponiéndose en el camino del usuario. De existir un conflicto leve frente a la comodidad del usuario, la seguridad máxima toma precedencia, aunque cuidados extremos deben llevarse a cabo con el fin de asegurarse que dichos permisos no reduzcan seriamente o solapadamente la usabilidad de las máquinas.
- Por ejemplo, si un programa es descubierto en el intento de violar una medida de seguridad, no se le preguntará al usuario para permitir dicha acción; que será simplemente negada. Si el usuario desea otorgar dicho permiso, ello puede ser hecho en la interfaz gráfica del centro de seguridad.
220 * Unobtrusive security 221 Whenever possible, the security on the machines must be behind the scenes, 222 making its presence known only through subtle visual or audio cues, and never 223 getting in the user's way. Whenever in conflict with slight user convenience, 224 strong unobtrusive security is to take precedence, though utmost care must be 225 taken to ensure such allowances do not seriously or conspicuously reduce the 226 usability of the machines. 227 228 As an example, if a program is found attempting to violate a security 229 setting, the user will not be prompted to permit the action; the action will 230 simply be denied. If the user wishes to grant permission for such an action, 231 she can do so through the graphical security center interface. 232 233
Objetivos
234 === Goals === 235
- Sin claves de usuario
- Con usuarios jóvenes (a partir de los cinco años), la seguridad de la laptop no puede depender del habilidad del usuario de recordar una clave. No se puede suponer que los usuarios elijan una clave cuando las reciban por primera vez.
236 * No user passwords 237 With users as young as 5 years old, the security of the laptop cannot depend 238 on the user's ability to remember a password. Users cannot be expected to 239 choose passwords when they first receive computers. 240
- Sin autentificación no-encriptada
- La autentificación de las laptops o sus usuarios no dependerá de identificadores transmitidos sin encriptar en la red. Esto quiere decir que claves visibles de ningún tipo pueden ser usadas en los protocolos OLPC y que el MAC de Ethernet jamás serán usados como autentificación.
241 * No unencrypted authentication 242 Authentication of laptops or users will not depend upon identifiers that are 243 sent unencrypted over the network. This means no cleartext passwords of any 244 kind will be used in any OLPC protocol and Ethernet MAC addresses will never 245 be used for authentication. 246
- Seguridad desde la caja
- La laptop deberá ser usable y segura desde la caja, sin necesidad de realizar o descargar actualizaciones de seguridad en la medidad de lo posible.
247 * Out-of-the-box security 248 The laptop should be both usable and secure out-of-the-box, without the need 249 to download security updates when at all possible. 250
- Uso limitado de PKI institucional
- La laptop estará provista con llaves públicas de la OLPC y la autoridad del el país o región (ej: ministerio o departamento de educación), pero estas llaves no serán usadas para validar la identidad de los usuarios. El único propósito de estas llaves es verificar la integridad del software y contenido incluído en la laptop. Los usuarios serán identificados por medio de un sistema orgánico PKI sin una cadena de confianza certificada (without a certified chain of trust)—en otras palabras, nuestro enfoque a PKI es KCM (Key-Continuity Management).
251 * Limited institutional PKI 252 The laptop will be supplied with public keys from OLPC and the country or 253 regional authority (e.g. the ministry or department of education), but these 254 keys will not be used to validate the identity of laptop users. The sole 255 purpose of these keys will be to verify the integrity of bundled software and 256 content. Users will be identified through an organically-grown PKI without a 257 certified chain of trust -- in other words, our approach to PKI is KCM, or 258 key continuity management. 259
- Sin pérdida permanente de datos
- La información en la laptop será replicada sobre algún almacenamiento centralizado de modo tal que el estudiante pueda recuperarla en el caso que la laptop se pierda, sea robada o destruida.
260 * No permanent data loss 261 Information on the laptop will be replicated to some centralized storage 262 place so that the student can recover it in the even that the laptop is lost, 263 stolen or destroyed. 264 265 266 267
Producción en planta
268 1. Factory production 269 ===================== 270
Como parte de su proceso de producción en la planta, ciertos datos relativos a su manufactura son grabados en un chip flash SPI embarcado. El chip es re-escribible, pero obviando la manipulación del hardware, solamente por un proceso de confianza que no dañará o modificará dicha información.
271 As part of factory production, certain manufacturing data is written to the 272 built-in SPI flash chip. The chip is rewritable, but barring hardware tampering, 273 only by a trusted process that will not damage or modify the manufacturing 274 information. 275
Los datos de manufactura incluyen dos identificadores únicos: NS, el número de serie (o SN - serial number) y U#, un UUID (universally unique identifier) generado al azar. Los números de serie no son asignados secuencialmente; sino que son elegidos al azar a partir de un conjunto de enteros. El proceso de manufactura mantiene la correspondencia entre numero de serie asignado al azar con el número de serie real secuencial que comenzó en 1 con la primera laptop producida. Esta correspondencia es confidencial pero no secreta, y es mantenida por la OLPC.
276 Manufacturing data includes two unique identifiers: SN, the serial number, 277 and U#, the randomly-generated UUID. Serial numbers are not assigned in 278 order; instead, they are chosen randomly from a pool of integers. The 279 manufacturing process maintains a mapping of the random serial number assigned, 280 to the real, incremental serial number which was set to 1 for the first laptop 281 produced. This mapping is confidential but not secret, and is kept by OLPC. 282
El único objetivo de esta correspondencia al azar es para desalentar cualquier intento de usar los números de series de las laptops entregadas en diferentes países para intentar analizar los volúmenes de compra de cada país.
283 The random mapping's sole purpose is to discourage attempts at using serial 284 numbers of laptops delivered to different countries for attempting to analyze 285 countries' purchase volumes. 286
El UUID de cada laptop, U#, es una secuencia al azar de 32 bytes ASCII imprimibles.
287 A laptop's UUID, U#, is a random 32-byte printable ASCII identifier. 288
En una de las etapas de diagnósticos en la planta tras haber sido producida, la herramienta de diagnóstico enviará toda la información relacionada a su manufactura, incluyendo el U#, NS y la información de la planta a un servidor de la OLPC. Esta información será encolada en la planta ante cualquier problema de conectividad, y por lo tanto no se perderá bajo ninguna situación prevista.
289 In one of the factory diagnostics stages after each laptop's production, the 290 diagnostics tool will send the complete manufacturing information, including U#, 291 SN, and factory information, to an OLPC server. This information will be queued 292 at the factory in case of connectivity issues, and so won't be lost under any 293 foreseeable circumstances. 294
Al salir de la linea de producción, la laptop se encuentra en modo "desactivada". Esto quiere decir que deberá pasar por el proceso de activación criptográfica cuando sea encendida, antes de poder ser usada por el usuario final.
295 At the end of the production line, the laptop is in the 'deactivated' state. 296 This means it must undergo a cryptographic activation process when powered on, 297 before it can be used by an end user. 298 299 300 301
Seguridad en la cadena de distribución
302 2. Delivery chain security 303 ========================== 304
La OLPC solo se encarga del embarque de las laptops de su planta de origen al país comprador. El despacho y distribución dentro de cada país es totalmente organizado y responsabilidad de cada país.
305 OLPC arranges only the shipment of laptops from their origin factory to each 306 purchasing country. Shipping and delivery within each country is organized fully 307 by the country. 308
Dados los volúmenes de producción de la OLPC, la cadena de distribución supone un vector de ataque atractivo para un ladrón emprendedor. El requerimiento para la activación torna el robo en la etapa de entrega inapetecible, requiriendo una intervención a nivel de hardware sobre cada laptop robada antes de su reventa. Damos una revista al proceso de activación más abajo.
309 Given OLPC production volumes, the delivery chain poses an attractive attack 310 vector for an enterprising thief. The activation requirement makes delivery 311 theft highly unappealing, requiring hardware intervention to disable on each 312 stolen laptop before resale. We give an overview of the activation process 313 below. 314 315 316 317
Arribo a la escuela y activacion
318 3. Arrival at school site and activation 319 ======================================== 320
Antes que una partida sea despachada a cada escuela, el país utiliza un software provisto por la OLPC para generar una partida de códigos de activación. Esta "lista de activación" posee la tupla (NS, UUID) y su correspondiente código de activación único para cada laptop referenciada. Las listas de activación son generadas por el mismo pais, a medida que las laptops son organizadas en partidas para ser entregadas a escuelas específicas. En otras palabras, no existe una lista maestra de activación.
321 Before a batch of laptops is shipped to each school, the country uses 322 OLPC-provided software to generate a batch of activation codes. This "activation 323 list" maps each (SN, UUID) tuple to a unique activation code for the referenced 324 laptop. Activation lists are generated on-demand by the country for each laptop 325 batch, as the laptops are partitioned into batches destined for specific 326 schools. In other words, there is no master activation list. 327
La lista de activación para cada partida de laptops es cargada a un disco USB, y entregada al responsable de las entregas del proyecto en la escuela destinataria fuera del circuito de entrega efectivo de las laptops. Este responsable de las entregas será comunmente un maestro u otro funcionario administrativo de la escuela. La lista de activación enviada a una escuela no puede ser usada para activar ninguna otra partida.
328 The activation list for a laptop batch is loaded onto a USB drive, and delivered 329 to a project handler in the target school out of band from the actual laptop 330 shipment. The handler will be commonly a teacher or other school administrator. 331 The activation list sent to one school cannot be used to activate any other 332 laptop batch. 333
Cuando el la lista de activación en el disco USB es recibida, este será conectado al servidor provisto por la OLPC, u otro servidor que pueda ejecutar el software requerido y que se encuentre conectado a un punto de acceso inalámbrico. Cualquier servidor que tome este rol será referido como el 'servidor de activación'. Una laptop XO activada podría ser usada para este propósito de ser necesario.
334 When the activation list USB drive is received, it is plugged into the 335 OLPC-provided school server, or another server running the requisite software 336 that is connected to a wireless access point. Whichever server takes on this 337 role will be called the 'activation server'. An activated XO laptop can be used 338 for this purpose, if necessary. 339
Tras la recepción de la partida de laptops correspondiente, el responsable de distribución de la escuela tendrá la tarea de entregar a cada chico su laptop. Cuando un chico reciba una laptop, esta estará aún desactivada. Será el chico quien deberá encender la laptop dentro del alcance del punto de acceso inalámbrico del servidor de activación. Cuando esto ocurra, la laptop comunicará de forma segura su tupla (NS, UUID) al servidor, el cual retornará el código de activación en cuestión, suponiendo que la tupla se encuentra en la lista de activación, o un error de no ser así.
340 After receiving the matching laptop batch, the school's project handler will be 341 tasked with giving a laptop to each child at the school. When a child receives 342 a laptop, it is still disabled. The child must power on the laptop within 343 wireless range of the school's activation server. When this happens, the laptop 344 will securely communicate its (SN, UUID) tuple to the server, which will return 345 the activation code for the laptop in question, provided the tuple is found in 346 the activation list, or an error if it isn't. 347
Dado un código de activación inválido o un error, la laptop dormirá durante una hora antes de volver a intentar su activación. Si el código de activación es válido, la laptop esta 'activada', y procede a la primera pantalla de encendido. Un código de activación textual puede ser ingresado manualmente en la máquina, si no se activara automáticamente por alguna razón.
348 Given an invalid activation code or an error, the laptop will sleep for one 349 hour before retrying activation. If the activation code is valid, the laptop 350 becomes 'activated', and proceeds to boot to the first-boot screen. A textual 351 activation code can be entered into the machine manually, if the machine is not 352 activating automatically for any reason. 353 354 355 356
Primer encendido
357 4. First boot 358 ============= 359
La primera vez que se enciende, un programa se ejecuta preguntandole al chico su nombre, toma una foto, y genera el par de claves ECC en el interin. El par de claves no se encuentra inicialmente protegido por una frase de paso (passphrase) y es asi usada para firmar tanto el nombre como la foto del chico. Esta informacion y la firma son la 'identidad digital' del chico.
360 On first boot, a program is run that asks the child for their name, takes 361 their picture, and in the background generates an ECC key pair. The key pair is 362 initially not protected by a passphrase, and is then used to sign the child's 363 name and picture. This information and the signature are the child's 'digital 364 identity'. 365
La laptop transmite la tupla (NS, UUID, identidad digital) al servidor de activación. La correspondencia entre la laptop y la identidad del usuario es mantenida por las autoridades regionales o nacionales con fines anti-robo, pero nunca llega a la OLPC.
366 The laptop transmits the (SN, UUID, digital identity) tuple to the activation 367 server. The mapping between a laptop and the user's identity is maintained by 368 the country or regional authority for anti-theft purposes, but never reaches 369 OLPC. 370
Después de esto, la laptop se inicia normalmente, con toda la seguridad activada.
371 After this, the laptop boots normally, with all security settings enabled. 372 373 374 375
Instalación de software
376 5. Software installation 377 ======================== 378
Hay una distinción importante entre dos amplios tipos de programas que se ejecutan en un sistema, y esta distinción no usualmente es mencionada en la literatura sobre seguridad. Existen programas que son intencionalmente maliciosos, implicando que son escritos con dichos fines desde un principio, como los virus y worms, y otros programas que son circunstancialmente maliciosos pero que de otro modo son benignos, tales como programas legítimos que han sido vulnerados por un atacante mientras se ejecutan, y son utilizados para ejecutar código para el atacante por medio de la inyección de código u otro mecanismo.
379 There is a very important distinction between two broad classes of programs 380 that execute on a running system, and this distinction is not often mentioned 381 in security literature. There are programs that are purposely malicious, 382 which is to say that they were written with ill intent from the start, such as 383 with viruses and worms, and there are programs which are circumstantially 384 malicious but otherwise benign, such as legitimate programs that have been 385 exploited by an attacker while they're running, and are now being instrumented 386 to execute code on behalf of the attacker via code injection or some other 387 method. 388
Esta diferenciación es crucial y no puede ser subestimada, pues es un supuesto razonable que la mayor parte del software ejecutandose en una máquina normal comienza como benigno. De hecho, hemos observado que es por medio de la usurpación del software benigno que la mayor parte del software maligno es _introducido_ por primera vez en muchas máquinas, por lo tanto, el proteger al software benigno se convierte en algo doblemente importante.
389 This difference is crucial and cannot be understated, because it's a 390 reasonable assumption that most software running on a normal machine starts 391 benign. In fact, we observe that it is through exploitation of benign software 392 that most malicious software is first _introduced_ to many machines, so 393 protecting benign software becomes a doubly worthy goal. 394
La protección del software benigno es una piedra fundamental en nuestro modelo de seguridad. Y lo utilizamos con la siguiente idea en mente: el software benigno no mentirá sobre sus propósitos durante su instalación.
395 The protection of benign software is a keystone of our security model. We 396 approach it with the following idea in mind: benign software will not lie about 397 its purpose during installation. 398
Como ejemplo, tomemos el juego de Solitario distribuído con muchas versiones de Microsoft Windows. Dicho programa no necesita:
- ningún tipo de acceso a la red
- ninguna capacidad de lectura de los documentos del usuario
- ninguna capacidad para utilizar la cámara o micrófono embarcados
- ninguna capacidad para mirar, o modificar, otros programas
399 To provide an example, consider the Solitaire game shipped with most versions 400 of Microsoft Windows. This program needs: 401 402 * no network access whatsoever 403 * no ability to read the user's documents 404 * no ability to utilize the built-in camera or microphone 405 * no ability to look at, or modify, other programs 406
Y si de algún modo es vulnerado por un atacante, el Solitario es libre de hacer cualquier cosa que desee el atacante, incluyendo:
- leer, corromper o borrar documentos del usuario, planillas de cálculo, música, fotos, y cualquier otro archivo
- espiar al usuario via la cámara o micrófono
- remplazar el fondo de pantalla del usuario
- acceder a las palabras claves de los sitios del usuario
- infectar otros programas en disco rígido con un virus
- descargar archivos a la máquina del usuario
- recibir o enviar correo electrónico a nombre del usuario
- hacer ruidos fuertes o embarazosos con los parlantes
407 Yet if somehow compromised by an attacker, Solitaire is free to do whatever the 408 attacker wishes, including: 409 410 * read, corrupt or delete the user's documents, spreadsheets, music, 411 photos and any other files 412 * eavesdrop on the user via the camera or microphone 413 * replace the user's wallpaper 414 * access the user's website passwords 415 * infect other programs on the hard drive with a virus 416 * download files to the user's machine 417 * receive or send e-mail on behalf of the user 418 * play loud or embarassing sounds on the speakers 419
El punto crítico aca no es que el Solitario jamás debería ser permitido el realizar cualquiera de las acciones mencionadas (que claramente no debería), sino que sus creadores _saben_ que jamás debería hacerlas. De esto se deduce que si el sistema tuviera la capacidad por la cual el Solitario indicara esto al momento de su instalación, el Solitario podría renunciar irreversiblemente a ciertos privilegios cuando sea instalado, lo cual limita severamente o destruye totalmente su utilidad para cualquier atacante.
420 The critical observation here is not that Solitaire should never have the 421 ability to do any of the above (which it clearly shouldn't), but that its 422 creators _know_ it should never do any of the above. It follows that if the 423 system implemented a facility for Solitaire to indicate this at installation 424 time, Solitaire could irreversibly shed various privileges the moment it's 425 installed, which severely limits or simply destroys its usefulness to an 426 attacker were it taken over. 427
Las laptops XO de la OLPC proveen justamente dicha facilidad. La instalación de programas no pasa simplemente por la ejecución del instalador, que es a su vez otro programa, sino a traves de un servicio de instalación del sistema que sabe cómo instalar paquetes de programas XO. Durante la instalación, el servicio de instalación le preguntará al paquete por los permisos de seguridad deseados, y posteriormente notificará al Servicio de Seguridad apropiadamente. Una vez instalado, la lista de permisos por programa solamente será modificable por el usuario por medio de la interfaz gráfica.
428 The OLPC XO laptops provide just such a facility. Program installation does 429 not occur through the simple execution of the installer, which is yet another 430 program, but through a system installation service which knows how to install 431 XO program bundles. During installation, the installer service will query 432 the bundle for the program's desired security permissions, and will notify 433 the system Security Service accordingly. After installation, the 434 per-program permission list is only modifiable by the user through a 435 graphical interface. 436
Un programa benigno como el Solitario simplemente no solicitaría permisos especiales durante su instalación, y llegado su usurpación, sería incapaz de realizar algo particularmente dañino, como alguna de las acciones enumeradas en la lista arriba.
437 A benign program such as Solitaire would simply not request any special 438 permissions during installation, and if taken over, would not be able to 439 perform anything particularly damaging, such as the actions from the above 440 list. 441
Cabe resaltar que dicho sistema _solo_ protege al software benigno. El problema todavía existe con el software intencionalmente malicioso, que bien podría solicitar todos los permisos durante su instalación y abusarlos arbitrariamente cuando sea ejecutado. Para evitar eso es que hacemos ciertos permisos durante la instalación mutuamente excluyentes, lo cual de hecho torna difícil que un programa malicioso solicite un conjunto de permisos que le permitan facilmente realizar acciones maliciosas. Los detalles de dichos mecanismos se encuentra más adelante en este documento.
442 It must be noted here that this system _only_ protects benign software. The 443 problem still remains of intentionally malicious software, which might request 444 all available permissions during installation in order to abuse them 445 arbitrarily when run. We address this by making certain initially-requestable 446 permissions mutually exclusive, in effect making it difficult for malicious 447 software to request a set of permissions that easily allow malicious action. 448 Details on this mechanism are provided later in this document. 449
Como nota final, los programas con firmas criptográficas de la OLPC o de los países individuales pueden evitar los límites a la solicitud de permisos, y de hecho solicitar cualquier conjunto de permisos deseado al momento de su instalación.
450 As a final note, programs cryptographically signed by OLPC or the 451 individual countries may bypass the permission request limits, and request 452 any permissions they wish at installation time. 453 454 455 456
Ejecución de software: el problema
457 6. Software execution: problem statement 458 ======================================== 459
El modelo de riesgo que intentamos lograr mientras la máquina está corriendo es uno difícil: deseamos tener la capacidad de ejecutar código usualmente sin confianza, al mismo tiempo que limitamos severamente su capacidad de producir daño al sistema.
460 The threat model that we are trying to address while the machine is running 461 normally is a difficult one: we wish to have the ability to execute generally 462 untrusted code, while severely limiting its ability to inflict harm to the 463 system. 464
Muchos de los dispositivos digitales son más vistos o vendidos como embarcados o computadoras administradas que como laptops o máquinas de escritorio personales (un ejemplo es el comunicador PIC de AMD que esquiva el problema del código no confiable completamente, logrando una inmunidad a los virus, malware y spyware permitiendo solamente la ejecución exclusiva de código firmado criptográficamente por el vendedor. En la práctica, esto quiere decir que el usuario esta limitado a la utilización de un conjunto muy limitado de programas provistos por el vendedor, y que no puede desarrollar su propio software o utilizar el de terceros. Si bien esta aproximación a la seguridad limita definitivamente ciertos vectores de ataques, debe ser recalcado que no es una solución definitiva (o silver bullet). Una computadora que no puede ser libremente programada representa una disminución enorme en la utilidad a la cual la mayoría de los usuarios se han acostumbrado y esperan—pero aún si ignoramos esto y nos enfocamos solamente en las calificaciones técnicas de un tal sistema de seguridad, debemos resaltar que casi siempre, las firmas criptográficas de los binarios son revisadas al momento de carga, no continuamente durante su ejecución. Con lo cual, las vulnerabilidades existentes en los binarios provistos por el vendedor aún permiten dañar al sistema. De igual modo, el sistema falla al no proveer ninguna protección contra ataques macro.
465 Many computer devices that are seen or marketed more as embedded or managed 466 computers than personal laptops or desktops (one example is AMD's [[PIC 467 communicator -> http://www.amdboard.com/pic.html]]) purport to dodge the 468 issue of untrusted code entirely, while staving off viruses, malware and 469 spyware by only permitting execution of code cryptographically signed by the 470 vendor. In practice, this means the user is limited to executing a very 471 restricted set of vendor-provided programs, and cannot develop her own software 472 or use software from third party developers. While this approach to security 473 certainly limits available attack vectors, it should be noted it is pointedly 474 not a silver bullet. A computer that is not freely programmable represents a 475 tremendous decrease in utility from what most consumers have come to expect 476 from their computers -- but even if we ignore this and focus merely on the 477 technical qualifications of such a security system, we must stress that almost 478 always, cryptographic signatures for binaries are checked at load time, not 479 continually during execution. Thus exploits for vendor-provided binaries are 480 still able to execute and harm the system. Similarly, this system fails to 481 provide any protection against macro attacks. 482
Como fue mencionado en la introducción, este modelo de ejecución restringido definitivamente no es una opción para las laptops XO. Aún más, queremos explícitamente incentivar y motivar a nuestros usuarios, los chicos, a participar en una situacion que sería una pesadilla para cualquier experto en seguridad: el compartir fácilmente código entre computadoras.
483 As we mention in the introduction, this severely restricted execution model is 484 absolutely not an option for the XO laptops. What's more, we want to explicitly 485 encourage our users, the children, to engage in a scenario certain to give 486 nightmares to any security expert: easy code sharing between computers. 487
Como parte de nuestra misión educativa, estamos facilitando a los chicos la capacidad de ver el código del programa que esten corriendo—tanto es así que proveemos la tecla de Ver Código Fuente en el teclado con ese fin—y también estamos haciendoles igualmente fácil el escribir su propio código en Python, nuestro lenguaje de programación por elección. Dado nuestro continuo enfasis en la colaboración como una característica directamente integrada al sistema operativo, el escenario donde un chico desarrolla algún software y desea compartirlo con sus amigos se convierte en algo natural, y que debe ser bien soportado.
488 As part of our educational mission, we're making it very easy for children to 489 see the code of the programs they're running -- we even provide a View 490 Source key on the keyboard for this purpose -- and are making it similarly easy 491 for children to write their own code in Python, our programming language of 492 choice. Given our further emphasis on collaboration as a feature integrated 493 directly into the operating system, the scenario where a child develops some 494 software and wishes to share it with her friends becomes a natural one, and one 495 that needs to be well-supported. 496
Desafortunadamente, el software recibido por medio de un amigo o conocido carece de toda confianza, dado que no existe una correspondencia de la confianza entre personas y software: confiar en un amigo no es, y no puede ser, lo mismo que confiar el código proveniente de dicho amigo. La máquina del amigo puede estar bajo el control de otro, y puede estar intentando enviar código malicioso a todos sus amigos, o el amigo puede querer estar tratando de hacer una jugarreta, o puede haber escrito—ya sea por ignorancia o malicia—software que a veces es malicioso.
497 Unfortunately, software received through a friend or acquaintance is completely 498 untrusted code, because there's no trust mapping between people and software: 499 trusting a friend isn't, and cannot be, the same as trusting code coming from 500 that friend. The friend's machine might be taken over, and may be attempting to 501 send malicious code to all her friends, or the friend might be trying to execute 502 a prank, or he might have written -- either out of ignorance or malice -- 503 software that is sometimes malicious. 504
Es con éste trasfondo que hemos construído las protecciones de seguridad en la laptop. Una oración capaz de resumir las intenciones de nuestro modelo de seguridad completamente es que "intenta prevenir que el software haga cosas malas". El siguiente capítulo explica las cinco categorías de 'cosas malas' que un software malicioso puede hacer, y el capítulo posterior las protecciones mismas. El capítulo 9 explica el rol de cada protección participa dentro del modelo de riesgos.
505 It is against this background that we've constructed security protections for 506 software on the laptop. A one-sentence summary of the intent of our complete 507 software security model is that it "tries to prevent software from doing bad 508 things". The next chapter explains the five categories of 'bad things' that 509 malicious software might do, and the chapter after that our protections 510 themselves. Chapter 9 explains how each protection addresses the threat model. 511 512 513 514
Modelo de riesgo: las cosas malas que el software puede hacer
515 7. Threat model: bad things that software can do 516 ================================================== 517
En el contexto y propósito de la discusión, existen cinco grandes categorías de "cosas malas" que la ejecución del software puede realizar. Sin un orden particular, el software puede intentar dañar la máquina, vulnerar la privacidad del usuario, dañar la información del usuario, hacer "cosas malas" a otras personas aparte del usuario de la máquina, y por último, suplantar al usuario.
518 There are five broad categories of "bad things" that running software could do, 519 for the purposes of our discussion. In no particular order, software can attempt 520 to damage the machine, compromise the user's privacy, damage the user's 521 information, do "bad things" to people other than the machine's user, and 522 lastly, impersonate the user. 523 524 525
Dañar la máquina
526 7.1. Damaging the machine 527 ------------------------- 528
El software que desee de algún modo inutilizar la laptop tiene por lo menos cinco vectores de ataque. Puede intentar arruinar la BIOS de la máquina, evitando que arranque. Puede intentar gastar el chip NAND utilizado como almacenamiento primario, que—siendo un chip flash—tiene un número limitado de ciclos de escritura/borrado antes de cesar de operar correctamente y requerir su remplazo. Ataques exitosos a la BIOS o NAND producen daño físico a la máquina, lo que implica que esas laptops requerirán de servicio técnico especializado, incluyendo el remplazo de partes, para su recuperación. El tercer vector, borrado o daño del sistema operativo, es una incomodidad que requerirá que la máquina sea re-espejada (re-imaged) y activada para su recuperación.
529 Software wishing to render a laptop inoperable has at least five attack 530 vectors. It may try to ruin the machine's BIOS, preventing it from booting. It 531 may attempt to run down the NAND chip used for primary storage, which -- being 532 a flash chip -- has a limited number of write/erase cycles before ceasing to 533 function properly and requiring replacement. Successful attacks on the BIOS or 534 NAND cause hard damage to the machine, meaning such laptops require trained 535 hardware intervention, including part replacement, to restore to operation. The 536 third vector, deleting or damaging the operating system, is an annoyance that 537 would require the machine to be re-imaged and reactivated to run. 538
Dos otros modos de dañar la máquina causan un daño leve: ellos reducen significativamente su utilidad. Estos ataques son degradación de performance y consumo de batería (con la salvedad que ciertas variantes del primero pueden efectivametne producir el segundo).
539 Two other means of damaging the machine cause soft damage: they significantly 540 reduce its utility. These attacks are performance degradation and battery 541 drainage (with the side note that variants of the former can certainly cause the 542 latter.) 543
Cuando nos referimos a la degradación de performance, nos estamos refiriendo a la sobre-utilizacion de cualquier recurso del sistema como la RAM, la CPU o el chip de red, de modo tal que el sistema se torna lento o que no responda para otros usos. El consumo de la batería puede ser un efecto colateral de dicha degradación maliciosa de la performance (ej: al evitar las medidas habituales de conservación de energía y la sobre-utilización de dispositivos de hardware glotones energéticos), o pueden ser realizados por algún otro medio. Una vez que se obtengan las mediciones de energía completas de nuestro hardware, estaremos en condiciones de determinar si existen canales alternativos para el consumo de grandes cantidades de energía de la batería sin un impacto en la performance general; esta sección será actualizada reflejando dicha información.
544 When we say performance degradation, we are referring to the over-utilization of 545 any system resource such as RAM, the CPU or the networking chip, in a way that 546 makes the system too slow or unresponsive to use for other purposes. Battery 547 drainage might be a side-effect of such a malicious performance degradation 548 (e.g. because of bypassing normal power saving measures and over-utilization of 549 power-hungry hardware components), or it might be accomplished through some 550 other means. Once we can obtain complete power measurements for our hardware 551 system, we will be aware of whether side channels exist for consuming large 552 amounts of battery power without general performance degradation; this section 553 will be updated to reflect that information. 554 555 556
Vulnerar la privacidad
557 7.2. Compromising privacy 558 ------------------------- 559 560 We see two primary means of software compromising user privacy: the 561 unauthorized sending of user-owned information such as documents and images 562 over the network, and eavesdropping on the user via the laptops' built-in 563 camera and microphone. 564 565 566
Daniar los datos del usuario
567 7.3. Damaging the user's data 568 ----------------------------- 569 570 A malicious program can attempt to delete or corrupt the user's documents, 571 create large numbers of fake or garbage-filled documents to make it difficult 572 for the user to find her legitimate ones, or attack other system services that 573 deal with data, such as the search service. Indeed, attacking the global 574 indexing service might well become a new venue for spam, that would thus show 575 up every time the user searched for anything on her system. Other attack 576 vectors undoubtedly exist. 577 578 579
Hacer cosas malas a otras personas
580 7.4. Doing bad things to other people 581 ------------------------------------- 582 583 Software might be malicious in ways that do not directly or strongly affect the 584 machine's owner or operator. Examples include performing Denial of Service 585 attacks against the current wireless or wired network (a feat particularly easy 586 on IPv6 networks, which our laptops will operate on by default), becoming a 587 spam relay, or joining a floodnet or other botnet. 588 589 590
Suplantar al usuario
591 7.5. Impersonating the user 592 --------------------------- 593 594 Malicious software might attempt to abuse the digital identity primitives on 595 the system, such as digital signing, to send messages appearing to come from 596 the user, or to abuse previously authenticated sessions that the user might 597 have created to privileged resources, such as the school server. 598 599 600 601
Protecciones
602 8. Protections 603 ============== 604 605 Here, we explain the set of protections that make up the bulk of the Bitfrost 606 security platform, our name for the sum total of the laptop's security systems. 607 Each protection listed below is given a concise uppercase textual label 608 beginning with the letter P. This label is simply a convenience for easy 609 reference, and stands for both the policy and mechanism of a given protection 610 system. 611 612 Almost all of the protections we discuss can be disabled by the user through a 613 graphical interface. While the laptop's protections are active, this interface 614 cannot be manipulated by the programs on the system through any means, be 615 it synthetic keyboard and mouse events or direct configuration file 616 modification. 617 618 619
P_BIOS_CORE: proteccion del nucleo de la BIOS
620 8.1. P_BIOS_CORE: core BIOS protection 621 -------------------------------------- 622 623 The BIOS on an XO laptop lives in a 1MB SPI flash chip, mentioned in Section 624 1.1. This chip's purpose is to hold manufacturing information about the machine 625 including its (SN, UUID) tuple, and the BIOS and firmware. Reflashing the 626 stored BIOS is strictly controlled, in such a way that only a BIOS image 627 cryptographically signed by OLPC can be flashed to the chip. The firmware will 628 not perform a BIOS reflashing if the battery level is detected as low, to avoid 629 the machine powering off while the operation is in progress. 630 631 A child may request a so-called developer key from OLPC. This key, bound to the 632 child's laptop's (SN, UUID) tuple, allows the child to flash any BIOS she 633 wishes, to accommodate the use case of those children who progress to be very 634 advanced developers and wish to modify their own firmware. 635 636 637
P_BIOS_COPY: Proteccion de la BIOS secundaria
638 8.2. P_BIOS_COPY: secondary BIOS protection 639 ----------------------------------------------- 640 641 The inclusion of this protection is uncertain, and depends on the final size of 642 the BIOS and firmware after all the desired functionality is included. The SPI 643 flash offers 1MB of storage space; if the BIOS and firmware can be made to fit 644 in less than 512KB, a second copy of the bundle will be stored in the SPI. This 645 secondary copy would be immutable (cannot be reflashed) and used to boot the 646 machine in case of the primary BIOS being unbootable. Various factors might 647 lead to such a state, primarily hard power loss during flashing, such as 648 through the removal of the battery from the machine, or simply a malfunctioning 649 SPI chip which does not reflash correctly. This section will be updated once it 650 becomes clear whether this protection can be included. 651 652 653
P_SF_CORE: Proteccion del nucleo del sistema de archivos
654 8.3. P_SF_CORE: core system file protection 655 ----------------------------------------------- 656 657 The core system file protection disallows modification of the stored system 658 image on a laptop's NAND flash, which OLPC laptops use as primary storage. 659 While engaged, this protection keeps any process on the machine from altering 660 in any way the system files shipped as part of the OLPC OS build. 661 662 This protection may not be disabled without a developer key, explained in 663 Section 8.1. 664 665 666
P_SF_RUN: Proteccion del sistema de archivos ejecutandose
667 8.4. P_SF_RUN: running system file protection 668 --------------------------------------------- 669 670 Whereas P_SF_CORE protects the *stored* system files, P_SF_RUN protects the 671 *running* system files from modification. As long as P_SF_RUN is engaged, at 672 every boot, the running system is loaded directly from the stored system files, 673 which are then marked read-only. 674 675 When P_SF_RUN is disengaged, the system file loading process at boot changes. 676 Instead of loading the stored files directly, a COW (copy on write) image is 677 constructed from them, and system files from _that_ image are initialized as the 678 running system. The COW image uses virtually no additional storage space on the 679 NAND flash until the user makes modifications to her running system files, which 680 causes the affected files to be copied before being changed. These modifications 681 persist between boots, but only apply to the COW copies: the underlying system 682 files remain untouched. 683 684 If P_SF_RUN is re-engaged after being disabled, the boot-time loading of system 685 files changes again; the system files are loaded into memory directly with no 686 intermediate COW image, and marked read-only. 687 688 P_SF_CORE and P_SF_RUN do not inter-depend. If P_SF_CORE is disengaged and the 689 stored system files are modified, but P_SF_RUN is engaged, after reboot no 690 modification of the running system will be permitted, despite the fact that the 691 underlying system files have changed from their original version in the OLPC OS 692 build. 693 694 695
P_NET: Politica de proteccion de red
696 8.5. P_NET: network policy protection 697 ------------------------------------- 698 699 Each program's network utilization can be constrained in the following 700 ways: 701 702 * Boolean network on/off restriction 703 * token-bucketed bandwidth throttling with burst allowance 704 * connection rate limiting 705 * packet destination restrictions by host name, IP and port(s) 706 * time-of-day restrictions on network use 707 * data transfer limit by hour or day 708 * server restriction (can bind and listen on a socket), Boolean and 709 per-port 710 711 Reasonable default rate and transfer limits will be imposed on all non-signed 712 programs. If necessary, different policies can apply to mesh and access point 713 traffic. Additional restrictions might be added to this list as we complete 714 our evaluation of network policy requirements. 715 716 717
P_NAND_RL: Proteccion contra escritura/borrado de la NAND
718 8.6. P_NAND_RL: NAND write/erase protection 719 ------------------------------------------- 720 721 A token-bucketed throttle with burst allowance will be in effect for the JFFS2 722 filesystem used on the NAND flash, which will simply start delaying 723 write/erase operations caused by a particular program after its bucket is 724 drained. It is currently being considered that such a delay behaves as an 725 exponential backoff, though no decision has yet been made, pending some field 726 testing. 727 728 A kernel interface will expose the per-program bucket fill levels to 729 userspace, allowing the implementation of further userspace policies, such as 730 shutting down programs whose buckets remain drained for too long. These 731 policies will be maintained and enforced by the system Security Service, a 732 privileged userspace program. 733 734 735
P_NAND_QUOTA: Cuota de NAND
736 8.7. P_NAND_QUOTA: NAND quota 737 ----------------------------- 738 739 To prevent disk exhaustion attacks, programs are given a limited scratch 740 space in which they can store their configuration and temporary files, such as 741 various caches. Currently, that limit is 5MB. Additionally, limits will be 742 imposed on inodes and dirents within that scratch space, with values to be 743 determined. 744 745 This does not include space for user documents created or manipulated by the 746 program, which are stored through the file store. The file store is 747 explained in a later section. 748 749 750
P_MIC_CAM: Proteccion de la camara y microfono
751 8.8. P_MIC_CAM: microphone and camera protection 752 ------------------------------------------------ 753 754 At the first level, our built-in camera and microphone are protected by 755 hardware: an LED is present next to each, and is lit (in hardware, without 756 software control) when the respective component is engaged. This provides a 757 very simple and obvious indication of the two being used. The LEDs turning on 758 unexpectedly will immediately tip off the user to potential eavesdropping. 759 760 Secondly, the use of the camera and microphone require a special permission, 761 requested at install-time as described in Chapter 5, for each program 762 wishing to do so. This permission does not, however, allow a program to 763 instantly turn on the camera and microphone. Instead, it merely lets the 764 program _ask_ the user to allow the camera or microphone (or both) to be 765 turned on. 766 767 This means that any benign programs which are taken over but haven't 768 declared themselves as needing the camera or microphone cannot be used 769 neither to turn on either, NOR to ask the user to do so! 770 771 Programs which have declared themselves as requiring those privileges (e.g. 772 a VOIP or videoconferencing app) can instruct the system to ask the user for 773 permission to enable the camera and microphone components, and if the request 774 is granted, the program is granted a timed capability to manipulate the 775 components, e.g. for 30 minutes. After that, the user will be asked for 776 permission again. 777 778 As mentioned in Chapter 5, programs cryptographically signed by a 779 trusted authority will be exempt from having to ask permission to manipulate 780 the components, but because of the LEDs which indicate their status, the 781 potential for abuse is rather low. 782 783 784
P_CPU_RL: Limitando el uso de la CPU
785 8.9. P_CPU_RL: CPU rate limiting 786 -------------------------------- 787 788 Foreground programs may use all of the machine's CPU power. Background 789 programs, however, may use no more than a fixed amount -- currently we're 790 looking to use 10% -- unless given a special permission by the user. 791 792 The Sugar UI environment on the XO laptops does not support overlapping 793 windows: only maximized application windows are supported. When we talk about 794 foreground and background execution, we are referring to programs that are, or 795 are not, currently displaying windows on the screen. 796 797 798
P_RTC: Proteccion del reloj de tiempo real
799 8.10. P_RTC: real time clock protection 800 --------------------------------------- 801 802 A time offset from the RTC is maintained for each running program, and the 803 program is allowed to change the offset arbitrarily. This fulfills the need 804 of certain programs to change the system time they use (we already have a 805 music program that must synchronize to within 10ms with any machines with 806 which it co-plays a tune) while not impacting other programs on the system. 807 808 809
P_DSP_BG: Permiso de sonido de fondo
810 8.11. P_DSP_BG: background sound permission 811 ------------------------------------------- 812 813 This is a permission, requestable at install-time, which lets the program 814 play audio while it isn't in the foreground. Its purpose is to make benign 815 programs immune to being used to play annoying or embarrassing loud sounds 816 if taken over. 817 818 819
P_X: Proteccion del sistema de ventanas X
820 8.12. P_X: X window system protection 821 ------------------------------------- 822 823 When manually assigned to a program by the user through a graphical 824 security interface, this permission lets a program send synthetic mouse 825 X events to another program. Its purpose is to enable the use of 826 accessibility software such as an on-screen keyboard. The permission is NOT 827 requestable at install-time, and thus must be manually assigned by the user 828 through a graphical interface, unless the software wishing to use it is 829 cryptographically signed by a trusted authority. 830 831 Without this permission, programs cannot eavesdrop on or fake one another's 832 events, which disables key logging software or sophisticated synthetic event 833 manipulation attacks, where malicious software acts as a remote control for 834 some other running program. 835 836 837
P_IDENT: Servicio de identidad
838 8.13. P_IDENT: identity service 839 ------------------------------- 840 841 The identity service is responsible for generating an ECC key pair at first 842 boot, keeping the key pair secure, and responding to requests to initiate 843 signed or encrypted sessions with other networked machines. 844 845 With the use of the identity service, all digital peer interactions or 846 communication (e-mails, instant messages, and so forth) can be 847 cryptographically signed to maintain integrity even as they're routed through 848 potentially malicious peers on the mesh, and may also be encrypted in countries 849 where this does not present a legal problem. 850 851 852
P_SANDBOX: Carceles / jaulas de programas
853 8.14. P_SANDBOX: program jails 854 ---------------------------------- 855 856 A program on the XO starts in a fortified chroot, akin to a BSD jail, 857 where its visible filesystem root is only its own constrained scratch space. It 858 normally has no access to system paths such as /proc or /sys, cannot see other 859 programs on the system or their scratch spaces, and only the libraries it needs 860 are mapped into its scratch space. It cannot access user documents directly, 861 but only through the file store service, explained in the next section. 862 863 Every program scratch space has three writable directories, called 'tmp', 864 'conf', and 'data'. The program is free to use these for temporary, 865 configuration, and data (resource) files, respectively. The rest of the scratch 866 space is immutable; the program may not modify its binaries or core 867 resource files. This model ensures that a program may be restored to its 868 base installation state by emptying the contents of the three writable 869 directories, and that it can be completely uninstalled by removing its bundle 870 (scratch space) directory. 871 872 873
P_DOCUMENT: Servicio de almacenamiento de archivos
874 8.15. P_DOCUMENT: file store service 875 ------------------------------------ 876 877 Unlike with traditional machines, user documents on the XO laptop are not 878 stored directly on the filesystem. Instead, they are read and stored through 879 the file store service, which provides an object-oriented interface to user 880 documents. Similar in very broad terms to the Microsoft WinFS design, the file 881 store allows rich metadata association while maintaining traditional UNIX 882 read()/write() semantics for actual file content manipulation. 883 884 Programs on the XO may not use the open() call to arbitrarily open user 885 documents in the system, nor can they introspect the list of available 886 documents, e.g. through listing directory contents. Instead, when a program 887 wishes to open a user document, it asks the system to present the user with a 888 'file open' dialog. A copy-on-write version of the file that the user selects 889 is also mapped into this scratch space -- in effect, the file just "appears", 890 along with a message informing the program of the file's path within the 891 scratch space. 892 893 Unix supports the passing of file descriptors (fds) through Unix domain 894 sockets, so an alternative implementation of P_DOCUMENT would merely pass in 895 the fd of the file in question to the calling program. We have elected not to 896 pursue this approach because communication with the file store service does not 897 take place directly over Unix domain sockets, but over the D-BUS IPC mechanism, 898 and because dealing with raw fds can be a hassle in higher-level languages. 899 900 Benign programs are not adversely impacted by the need to use the file store 901 for document access, because they generally do not care about rendering their 902 own file open dialogs (with the rare exception of programs which create 903 custom dialogs to e.g. offer built-in file previews; for the time being, we 904 are not going to support this use case). 905 906 Malicious programs, however, lose a tremendous amount of ability to violate 907 the user's privacy or damage her data, because all document access requires 908 explicit assent by the user. 909 910 911
P_DOCUMENT_RO
912 8.16. P_DOCUMENT_RO 913 ------------------- 914 915 Certain kinds of software, such as photo viewing programs, need access to 916 all documents of a certain kind (e.g. images) to fulfill their desired 917 function. This is in direct opposition with the P_DOCUMENT protection which 918 requires user consent for each document being opened -- in this case, each 919 photo. 920 921 To resolve the quandary, we must ask ourselves: "from what are we trying to 922 protect the user?". The answer, here, is a malicious program which requests 923 permission to read all images, or all text files, or all e-mails, and then 924 sends those documents over the network to an attacker or posts them publicly, 925 seriously breaching the user's privacy. 926 927 We solve this by allowing programs to request read-only permissions for one 928 type of document (e.g. image, audio, text, e-mail) at installation time, but 929 making that permission (P_DOCUMENT_RO) mutually exclusive with asking for any 930 network access at all. A photo viewing program, in other words, normally 931 has no business connecting to the Internet. 932 933 As with other permissions, the user may assign the network permission to a 934 program which requested P_DOCUMENT_RO at install, bypassing the mutual 935 exclusion. 936 937 938
P_DOCUMENT_RL: Limitando el ritmo de almacenamiento de archivos
939 8.17. P_DOCUMENT_RL: file store rate limiting 940 --------------------------------------------- 941 942 The file store does not permit programs to store new files or new versions 943 of old files with a frequency higher than a certain preset, e.g. once every 30 944 seconds. 945 946 947
P_DOCUMENT_BACKUP: Servicio de respaldo de archivos
948 8.18. P_DOCUMENT_BACKUP: file store backup service 949 -------------------------------------------------- 950 951 When in range of servers that advertise themselves as offering a backup 952 service, the laptop will automatically perform incremental backups of user 953 documents which it can later retrieve. Because of the desire to avoid having to 954 ask children to generate a new digital identity if their laptop is ever lost, 955 stolen or broken, by default the child's ECC keypair is also backed up to the 956 server. Given that a child's private key normally has no password protection, 957 stealing the primary backup server (normally the school server) offers the 958 thief the ability to impersonate any child in the system. 959 960 For now, we deem this an acceptable risk. We should also mention that the 961 private key will only be backed up to the primary backup server -- usually in 962 the school -- and not any server that advertises itself as providing backup 963 service. Furthermore, for all non-primary backup servers, only encrypted 964 version of the incremental backups will be stored. 965 966 967
P_THEFT: Proteccion anti-robo
968 8.19. P_THEFT: anti-theft protection 969 ------------------------------------ 970 971 The OLPC project has received very strong requests from certain countries 972 considering joining the program to provide a powerful anti-theft service that 973 would act as a theft deterrent against most thieves. 974 975 We provide such a service for interested countries to enable on the laptops. It 976 works by running, as a privileged process that cannot be disabled or 977 terminated even by the root user, an anti-theft daemon which detects Internet 978 access, and performs a call-home request -- no more than once a day -- to the 979 country's anti-theft servers. In so doing, it is able to securely use NTP to 980 set the machine RTC to the current time, and then obtain a cryptographic lease 981 to keep running for some amount of time, e.g. 21 days. The lease duration is 982 controlled by each country. 983 984 A stolen laptop will have its (SN, UUID) tuple reported to the country's OLPC 985 oversight body in charge of the anti-theft service. The laptop will be marked 986 stolen in the country's master database. 987 988 A thief might do several things with a laptop: use it to connect to the 989 Internet, remove it from any networks and attempt to use it as a standalone 990 machine, or take it apart for parts. 991 992 In the former case, the anti-theft daemon would learn that the laptop is stolen 993 as soon as it's connected to the Internet, and would perform a hard shutdown 994 and lock the machine such that it requires activation, described previously, to 995 function. 996 997 We do not expect the machines will be an appealing target for part resale. Save 998 for the custom display, all valuable parts of the XO laptops are soldered onto 999 the motherboard. 1000 1001 To address the case where a stolen machine is used as a personal computer but 1002 not connected to the Internet, the anti-theft daemon will shut down and lock 1003 the machine if its cryptographic lease ever expires. In other words, if the 1004 country operates with 21-day leases, a normal, non-stolen laptop will get the 1005 lease extended by 21 days each day it connects to the Internet. But if the 1006 machine does not connect to the Internet for 21 days, it will shut down and 1007 lock. 1008 1009 Since this might present a problem in some countries due to intermittent 1010 Internet access, the leases can either be made to last rather long (they're 1011 still an effective theft deterrent even with a 3 month duration), or they can 1012 be manually extended by connecting a USB drive to the activation server. For 1013 instance, a country may issue 3-week leases, but if a school has a satellite 1014 dish failure, the country's OLPC oversight body may mail a USB drive to the 1015 school handler, which when connected to the school server, transparently 1016 extends the lease of each referenced laptop for some period of time. 1017 1018 The anti-theft system cannot be bypassed as long as P_SF_CORE is enabled (and 1019 disabling it requires a developer key). This, in effect, means that a child is 1020 free to do any modification to her machine's userspace (by disabling P_SF_RUN 1021 without a developer key), but cannot change the running kernel without 1022 requesting the key. The key-issuing process incorporates a 14-day delay to 1023 allow for a slow theft report to percolate up through the system, and is only 1024 issued if the machine is not reported stolen at the end of that period of time. 1025 1026 1027
P_SERVER_AUTH: Autentificacion transparente y segura a un servidor autorizado
1028 8.21. P_SERVER_AUTH: transparent strong authentication to trusted server 1029 ------------------------------------------------------------------------ 1030 1031 When in wireless range of a trusted server (e.g. one provided by OLPC or the 1032 country), the laptop can securely respond to an authentication challenge with 1033 its (SN, UUID) tuple. In addition to serving as a means for the school to 1034 exercise network access control -- we know about some schools, for instance, 1035 that do not wish to provide Internet access to alumni, but only current 1036 students -- this authentication can unlock extra services like backup and 1037 access to a decentralized digital identity system such as OpenID. 1038 1039 [[OpenID -> http://en.wikipedia.org/wiki/OpenID]] is particularly appealing 1040 to OLPC, because it can be used to perpetuate passwordless access even on sites 1041 that normally require authentication, as long as they support OpenID. The most 1042 common mode of operation for current OpenID identity providers is to request 1043 password authentication from the user. With an OpenID provider service running 1044 on the school server (or other trusted servers), logins to OpenID-enabled sites 1045 will simply succeed transparently, because the child's machine has been 1046 authenticated in the background by P_SERVER_AUTH. 1047 1048 1049
== (A futuro) P_PASSWORD: Proteccion con clave
1050 8.21. (For later implementation) P_PASSWORD: password protection 1051 ---------------------------------------------------------------- 1052 1053 It is unclear whether this protection will make it in to generation 1 of the XO 1054 laptops. When implemented, however, it will allow the user to set a password to 1055 be used for her digital identity, booting the machine, and accessing some of 1056 her files. 1057 1058 1059 1060
Considerando el modelo de riesgos
1061 9. Addressing the threat model 1062 ============================== 1063 1064 We look at the five categories of "bad things" software can do as listed in 1065 Chapter 7, and explain how protections listed in Chapter 8 help. The following 1066 sections are given in the same order as software threat model entries in 1067 Chapter 7. 1068 1069 1070
Daniando la maquina
1071 9.1. Damaging the machine 1072 ------------------------- 1073 1074 P_BIOS_CORE ensures the BIOS can only be updated by BIOS images coming from 1075 trusted sources. A child with a developer key may flash whichever BIOS she 1076 pleases, though if we are able to implement P_BIOS_COPY, the machine will 1077 remain operational even if the child flashes a broken or garbage BIOS. 1078 Programs looking to damage the OS cannot do so because of P_SANDBOX and 1079 P_SF_RUN. Should a user with P_SF_RUN disabled be tricked into damaging her OS 1080 or do so accidentally, P_SF_CORE enables her to restore her OS to its initial 1081 (activated) state at boot time. 1082 1083 Programs trying to trash the NAND by exhausting write/erase cycles are 1084 controlled through P_NAND_RL, and disk exhaustion attacks in the scratch space 1085 are curbed by P_NAND_QUOTA. Disk exhaustion attacks with user documents are 1086 made much more difficult by P_DOCUMENT_RL. 1087 1088 CPU-hogging programs are reined in with P_CPU_RL. Network-hogging programs are 1089 controlled by policy via P_NET. 1090 1091 1092
Vulnerando la privacidad
1093 9.2. Compromising privacy 1094 ------------------------- 1095 1096 Arbitrary reading and/or sending of the user's documents over the network is 1097 curbed by P_DOCUMENT, while tagging documents with the program that created 1098 them addresses the scenario in which a malicious program attempts to spam 1099 the search service. Search results from a single program can simply be 1100 hidden (permanently), or removed from the index completely. 1101 1102 P_DOCUMENT_RO additionally protects the user from wide-scale privacy breaches 1103 by software that purports to be a "viewer" of some broad class of documents. 1104 1105 P_MIC_CAM makes eavesdropping on the user difficult, and P_X makes it very hard 1106 to steal passwords or other sensitive information, or monitor text entry from 1107 other running programs. 1108 1109 1110
Daniando los datos del usuario
1111 9.3. Damaging the user's data 1112 ----------------------------- 1113 1114 File store does not permit programs to overwrite objects such as e-mail and 1115 text which aren't opaque binary blobs. Instead, only a new version is stored, 1116 and the file store exposes a list of the full version history. This affords a 1117 large class of documents protection against deletion or corruption at the hands 1118 of a malicious program -- which, of course, had to obtain the user's 1119 permission to look at the file in question in the first place, as explained in 1120 P_DOCUMENT. 1121 1122 For binary blobs -- videos, music, images -- a malicious program in which 1123 the user specifically opens a certain file does have the ability to corrupt or 1124 delete the file. However, we cannot protect the user from herself. We point 1125 out that such deletion is constrained to _only_ those files which the user 1126 explicitly opened. Furthermore, P_DOCUMENT_BACKUP allows a final way out even 1127 in such situations, assuming the machine came across a backup server (OLPC 1128 school servers advertise themselves as such). 1129 1130 1131
Haciendo cosas malas a otros
1132 9.4. Doing bad things to other people 1133 ------------------------------------- 1134 1135 XO laptops will be quite unattractive as spam relays or floodnet clients due to 1136 network rate and transfer limits imposed on all non-signed programs by 1137 P_NET. Despite the appeal of the XO deployment scale for spamming or flooding, 1138 we expect that a restriction to generally low-volume network usage for 1139 untrusted software -- coupled with the great difficulty in writing worms or 1140 self-propagating software for XO machines -- will drastically reduce this 1141 concern. 1142 1143 1144
Suplantando al usuario
1145 9.5. Impersonating the user 1146 --------------------------- 1147 1148 The design of the identity service, P_IDENT, does not allow programs to 1149 ever come in direct contact with the user's cryptographic key pair, nor to 1150 inject information into currently-open sessions which are using the identity 1151 service for signing or encryption. 1152 1153 1154
Varios
1155 9.6. Miscellaneous 1156 ------------------ 1157 1158 In addition to the protections listed above which each address some part of the 1159 threat model, permissions P_RTC and P_THEFT combine to offer an anti-theft 1160 system that requires non-trivial sophistication (ability to tamper with 1161 on-board hardware) to defeat, and P_DSP_BG provides protection against certain 1162 types of annoying malware, such as the infamous 1989 Yankee Doodle virus. 1163 1164 1165
Faltantes a esta lista
1166 9.7. Missing from this list 1167 --------------------------- 1168 1169 At least two problems, commonly associated with laptops and child computer 1170 users respectively, are not discussed by our threat model or protection 1171 systems: hard drive encryption and objectionable content filtering / parental 1172 controls. 1173 1174
Encriptacion del sistema de archivos
1175 === 9.7.1. Filesystem encryption === 1176 1177 While the XO laptops have no hard drive to speak of, the data encryption 1178 question applies just as well to our flash primary storage. The answer consists 1179 of two parts: firstly, filesystem encryption is too slow given our hardware. 1180 The XO laptops can encrypt about 2-4 MB/s with the AES-128 algorithm in CBC 1181 mode, using 100% of the available CPU power. This is about ten times less than 1182 the throughput of the NAND flash chip. Moving to a faster algorithm such as RC4 1183 increases encryption throughput to about 15 MB/s with large blocks at 100% CPU 1184 utilization, and is hence still too slow for general use, and provides 1185 questionable security. Secondly, because of the age of our users, we have 1186 explicitly designed the Bitfrost platform not to rely on the user setting 1187 passwords to control access to her computer. But without passwords, user data 1188 encryption would have to be keyed based on unique identifiers of the laptop 1189 itself, which lends no protection to the user's documents in case the laptop is 1190 stolen. 1191 1192 Once the Bitfrost platform supports the P_PASSWORD protection, which might not 1193 be until the second generation of the XO laptops, we will provide support for 1194 the user to individually encrypt files if she enabled the protection and set a 1195 password for herself. 1196 1197
Filtrado de contenido cuestionable
1198 === 9.7.2. Objectionable content filtering === 1199 1200 The Bitfrost platform governs system security on the XO laptops. Given that 1201 "objectionable content" lacks any kind of technical definition, and is instead 1202 a purely social construct, filtering such content lies wholly outside of the 1203 scope of the security platform and this document. 1204 1205 1206 1207
Descarte de la laptop y seguridad de transferencia
1208 10. Laptop disposal and transfer security 1209 ========================================= 1210 1211 The target lifetime of an XO laptop is five years. After this time elapses, the 1212 laptop's owner might wish to dispose of the laptop. Similarly, for logistical 1213 reasons, a laptop may change hands, going from one owner to another. 1214 1215 A laptop re-initialization program will be provided which securely erases the 1216 user's digital identity and all user documents from a laptop. When running in 1217 "disposal" mode, that program could also be made to permanently disable the 1218 laptop, but it is unclear whether such functionality is actually necessary, so 1219 there are no current plans for providing it. 1220 1221 1222 1223
Comentarios finales
1224 11. Closing words 1225 ================= 1226 1227 In Norse mythology, Bifröst is the bridge which keeps mortals, inhabitants of 1228 the realm of Midgard, from venturing into Asgard, the realm of the gods. In 1229 effect, Bifröst is a powerful security system designed to keep out unwanted 1230 intruders. 1231 1232 This is not why the OLPC security platform's name is a play on the name of the 1233 mythical bridge, however. What's particularly interesting about Bifröst is a 1234 story that 12th century Icelandic historian and poet Snorri Sturluson tells in 1235 the first part of his poetics manual called the Prose Edda. Here is the 1236 relevant excerpt from the 1916 translation by Arthur Gilchrist Brodeur: 1237 1238 Then said Gangleri: "What is the way to heaven from earth?" 1239 1240 Then Hárr answered, and laughed aloud: "Now, that is not wisely asked; has 1241 it not been told thee, that the gods made a bridge from earth, to heaven, 1242 called Bifröst? Thou must have seen it; it may be that ye call it rainbow.' 1243 It is of three colors, and very strong, and made with cunning and with more 1244 magic art than other works of craftsmanship. But strong as it is, yet must 1245 it be broken, when the sons of Múspell shall go forth harrying and ride it, 1246 and swim their horses over great rivers; thus they shall proceed." 1247 1248 Then said Gangleri: "To my thinking the gods did not build the bridge 1249 honestly, seeing that it could be broken, and they able to make it as they 1250 would." 1251 1252 Then Hárr replied: "The gods are not deserving of reproof because of this 1253 work of skill: a good bridge is Bifröst, but nothing in this world is of 1254 such nature that it may be relied on when the sons of Múspell go 1255 a-harrying." 1256 1257 This story is quite remarkable, as it amounts to a 13th century recognition of 1258 the idea that there's no such thing as a perfect security system. 1259 1260 To borrow Sturluson's terms, we believe we've imbued the OLPC security system 1261 with cunning and more magic art than other similar works of craftmanship -- but 1262 not for a second do we believe we've designed something that cannot be broken 1263 when talented, determined and resourceful attackers go forth harrying. Indeed, 1264 this was not the goal. The goal was to significantly raise the bar from the 1265 current, deeply unsatisfactory, state of desktop security. We believe Bitfrost 1266 accomplishes this, though only once the laptops are deployed in the field will 1267 we be able to tell with some degree of certainty whether we have succeeded. 1268 1269 If the subject matter interests you, please join the OLPC security mailing 1270 list, share your thoughts, and join the discussion. 1271 1272 1273 1274 1275 1276 END