cedric's bazaar

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Login ======

  * people can fully use Chromium OS without needing a Google login (fine);
  * plan to give SSO experience at OpenID relying parties;
  * user name will be hashed HASH(salt||user@domain.com). Web-based user name may contain characters that are not safe for use on the file system (nice side effect for the security).

====== Security ======
  * cgroups http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt Actually Chromium runs Linux 2.6.35;
  * cached data http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data#Appendix_D_Designs_considered
  * Suspending to RAM works already quite well with dm-crypt:
    * according to Google no concrete solutions against sophisticated attacks like Cold Boot Attacks on Encryption Keys http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data#TOC-Suspending-to-RAM, http://citp.princeton.edu/memory/
  * verified boot crypto specification:
    * developer builds do not use a verified boot;
    * the TPM is used as secure non-volatile storage for preventing key rollback attacks (not for the encryption);
    * Google plan is to use a 8192-bit RSA key with SHA-512 for the root key signatures (NIST recommends the use of RSA 2048/SHA-256 or higher as the signature algorithm for use after 12/31/2010);
    * signin keys will change offently (Google plan to use 1024-bit RSA keys which provides a good speed/performance trade-off);


==== Verified boot ====
Some attack cases (http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot#TOC-Attack-cases) considered by design.


===== Partition encryption =====
Each user is allocated one encrypted image file that can grow to fill the free space on its disk partition. The image file is stored in a directory specific to the user using a hash of the user name with a salt value. The image itself is a sparse file that is attached to the system through a loop device. Using the device mapper subsystem, a virtual, encrypting block device, dm-crypt, is layered on top of the loop device.

//
The image encryption key for the dm-crypt device is generated randomly during setup using the randomness generator provided by the kernel, and if supported, seeded by a hardware random number generator. It is then encrypted with a partial cryptographic hash derived from the user's Google Accounts password and stored with the encrypted image on the underlying file system. On login, the encryption key is decrypted, and the encrypted image is mounted over the user's home directory. If the user's password changes, the image encryption key is re-encrypted with a new weak hash generated from the new passphrase. There are still some outstanding issues around what happens if a user changes her password from a non-Chromium OS machine....//


====== Applications ======
  * Google Chromium OS applications for maximum security;
  * possible to install applications from external sources (like Android)
  * all HTML5-enabled web applications.