[OLPC Security] coment on file system encryption in XO

[Bipin Gautam]

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

Dear Ivan and all,

 I have few coments on your above statements. Please convince me. ;)

Does this mean we are dropping filesystem(FS) encryption for XO?
I have always doubt if XO will support FS encryption with password in
first place.

Here is why!
It is said in Bitfrost specification;
 8.18. P_DOCUMENT_BACKUP: file store backup service: By default the
child's ECC keypair is also backed up to the server. Given that a
child's private key normally has no password protection.

Note1: This means by default parents or teachers have access to all
the documents of laptop when explictly needed from the backup server.
Note2: If the laptop is stolen (or someome have phyical access) he/she
will have access to all the data of laptop anyways.
Note3: All services in the laptop run inside a sandbox so even if
there is a remotely exploitable vulnerability it would be very
difficult for an attacker to break the JAIL and access other
documents.

then why would OLPC impliment another layer of FS/DATA encryption and
to protect what? Except the fact to backup in non-primary backup
servers and secure the backup.

Secondly, I wounder why you think "moving to a faster algorithm such
as RC4 increases encryption throughput to about 15 MB/s BUT is still
too slow for general use, and provides questionable security."

Assuming, of the 512 MB total storage of XO, ~200MB is used for OS
then at 15MB/s the storage  will be completey filled in 300MB/15= 20
sec if a user has to write that much of data.

[i understand file/disk encryption(write) and decrtption(read) speed
slightly vary]
Anyone will rarely have such a heavy disk I/O in that limited storage.

Also note the fact with ~30 MB disk read (i assume, as i havent
tested) you could boot the XO.
I have attached a screenshot of KNOPPIX STD booted with fluxbox GUI
and after some time of system activity still the total IDE read was
just 26.6 MB.

( Nepal needs more test boards more testing & development ;(

if we decide to just encrypt    /home    i doubt if it will cause any
significant preformance degredation at 15MB/s.

> 1185 questionable security.

I assume you are talking about RC4. (correct me if i am wrong)
We arent here protecting "SECRET" or "TOP SECRET" document and should
be secured as per NSA  AES-192  standard. We are here just trying to
protect personal documents of KIDS so i believe RC4 should provide
sufficient protection considering factors as;
- Our users requirements and what they will be using it for (when necessary)
- Our Hardware limitations
- Value of documents that we will be protecting

Further more i believe for protection of "private key" there should be
a clear visual option (but unchecked by default) for password.

We've expect kids to use internet and learn stuffs everyday.
They(kids) will obviously be remembering URLs and PASSWORDS for
several online account anyways. So i doubt having this visual but
optional passowrd option will do any hinderance.

this much for now...

Some refrenses for the curious ones:
Bruce Schneier, Doug Whiting (2000-04-07). "A Performance Comparison
of the Five AES Finalists
http://www.schneier.com/paper-aes-comparison.html

http://www.schneier.com/blowfish-speed.html

Speed comparision of popular crypto algo:
http://www.cryptopp.com/benchmarks.html

also try these commands:
openssl speed rc4
openssl speed blowfish
openssl speed aes


with regards,
-bipin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: knoppixSTD+fluxbox GUI.jpg
Type: image/jpeg
Size: 141158 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/security/attachments/20070217/71499f2a/knoppixSTDfluxboxGUI-0001.jpg