Talk:OLPC Bitfrost

Enhanced Anti-theft

I gather the primary anti-theft lease mechanism completely disables boot from the protected SPI ROM code so that a thief cannot recover from lease expiry by booting from a thumb drive etc.

This meets the most urgent and primary requirement of discouraging widespread organized theft for resale.

A less important problem is recovery of laptops that have been stolen (or just "found") casually by people unaware that the laptop will stop functioning and who may destroy it or throw it away somewhere where it cannot be found rather than enabling its return when they discover it is useless to them (or may damage it in hope of fixing it or finding saleable parts).

In some environments the scale of casual theft and/or the lack of a norm for handing in lost and found property (eg with corrupt police etc), such recoveries could turn out to be significant.

A problem with the lease mechanism is that it may encourage a thief, or a person who finds a lost laptop and plays with for a while instead of returning it promptly, to destroy or secretly dispose of the laptop instead of allowing it to be found again and returned. During the period between stealing or finding a lost laptop and the lease expiry, a person who has started using it may have entered identifying data (including a photograph). Since they cannot delete this data when the laptop stops working and they find out about the lease mechanism, they could fear being caught (or unjustly accused) if the laptop is recovered, and take measures to protect themselves.

Proposed solution is instead of completely disabling any boot at all, set a flag that switches to booting only a specific environment that works in "kiosk mode" carefully limited and tested for no possibility of the user gaining control.

The problem is that organized commercial theft for resale could disable this mode by modifying the unprotected "kiosk mode" boot files during the period before the lease expires (since they cannot be stored within the protected area of the SPI ROM). It would be necessary to use cryptographic integrity checks (a signed file manifest with secure hashes) before loading them (and failsafe to no boot at all if they have been modified).

Provided that mechanism is available, the normal kernel and verified safe applications could be used, but with a patched environment that disables the keyboard etc and only autoloads in "kiosk mode".

In this "kiosk mode" the laptop would do nothing useful to its possessor but would periodically and automatically at random times turn itself on to inform them of the procedures for returning it and convincingly explain that there will be no repercussions from doing so. For example it could play audio, perhaps accompanied with comic strip graphics or even animations that have been localized for this purpose.

To conserve battery the message could either be stopped or paused when any key is pressed, but would always repeat at power on and random intervals.

This would be most useful together with an official government policy designating specific collection points (most obviously Post Offices). A copy of the official directive (with official looking signatures and logos) and reference to the relevant regulations addressed to the Post Office staff could be displayed on the screen and read out in the audio.

This would direct the recipient that anybody delivering a laptop is to be assumed to have found it lost and is not to be asked any questions regardless of any suspicions and that the laptops are to be despatched postage free (or guaranteed by recipient) to a specified Education Ministry address so that they can be returned to the owner. It would also explain that all data on the laptop has already been (securely) wiped and that this is part of a program intended to protect the privacy of the children who own them as well as to encourage people who find them to return them promptly when lost.

It is of course still necessary to be able to update and recover the laptop with the normal bitfrost secured procedures. Only after the flag has been set by lease expiry would the restriction that only permits recovery using the anti-theft keys kick in.

See Intel's Boot Integrity Services (Version 1.0) for an API that fully specifies complex PKI integrity checks for boot files (including provision for complex delegation of update authorizations between manufacturer (OLPC) and user IT organizations (national and regional Education authorities) and others (eg for use with indidivual "developer keys" provided to end users, presumably including all children when they leave school retaining their laptops). This is designed for use with the PXE Preboot Execution Environment and presumably source code implementations are readily available as PXE is used upstream with Linux on PC's with typical BIOSes supported by Red Hat.

Presumably the standard Bitfrost mechanisms for signed manifests would be similar but the document is useful for specifying a complex delegation model for updates etc, with management software available to handle the actual administration.

The same mechanism can of course be used to provide reassurance that the laptop is not "broken" when a lease expires due to a child moving from a school etc with instructions on how to recover.

In addition it could be used to track down lost or stolen laptops by making regular probes for a designated WiFi SSID and/or responding to such beacons. All XOs (and repeaters etc) would be configured with any school server (anywhere) to coordinate triangulation of missing laptops using the mechanisms that are already deployed for 911 locality services and will no doubt eventually be implemented for pictorial displays of mesh neigbourhoods on XOs (but in this case, not showing up in the normal display available to all, but silently notified to whoever is designated to attempt recovery).

Perhaps this could be done for a period of several days (but less than a full lease expiry period) when a missing laptop has been registered to be disabled when it "calls home" on connecting to the internet. That might achieve a higher recovery rate than using the internet connection for immediate shut down as the casual thief/finder would continue operating them while being tracked. This delay could also avoid wiping the child's data since the last backup if it resulted in recovery before the full shutdown to kiosk mode occurs.

The space occupied by the multimedia warnings/recovery instructions could be treated as simply reserved space with provision in the UI for deleting them to recover from "out of space" conditions (eg a "use emergency reserve space" option in the notification of no more room). Backup and archiving procedures would automatically restore the files whenever they are noticed missing and there is sufficient room. Such a facility could be useful anyway (perhaps with a larger reserve).

Possible "virus"

The design goals of the laptop, including collaboration and modification of source code, make certain kinds of cross-computer self-replicating code possible. For instance, a program with network privs could watch for other users collaboratively using the "develop" activity and "suggest" the insertion of malicious code. Obviously, this is not a major threat, as such a virus would be dependent on user actions at the receiving end, but should be considered.

In order to stop this kind of activity, various finer-grained security privileges would work. For instance, the identity service in P_IDENT could include the registered name of the initiating application and its provenance (signed or unsigned) as a part of any signature. There could be separate network privileges for foreground and background/server use. And there could be a set of "remote privileges" for the kinds of communication an app could carry out with other bitfrost-aware clients - only with apps of the same name, for instance.

On the other side, there are some use-cases which are not covered by this model as described.

• The develop activity itself needs some P_SOURCE access beyond the regular P_DOCUMENT.
• For both P_DOCUMENT and P_SOURCE, the application can take a document handler initially and not just from the "open" dialogue box.
• A P_DOCUMENT_RO browser should be, by default, able to cause a document to open, either with its default handler app or using the os-provided "open with" dialogue.
• There should be a P_DOCUMENT_METADATA that allows a P_DOCUMENT_RO app to do tagging tasks. (Note that if tags are used by the journal for assigning sharing scope, this would be a security hole. I think that a browser app should have its writeable tagging namespace restricted, and that any attempt to use a member of such a namespace for sharing in the journal app should throw up a security confirmation dialog.)
• Privileges for interapplication communication on the same machine.

Homunq 10:48, 29 July 2007 (EDT)