A technical assessment of porting "Sugar" to Windows.

[Carl-Daniel Hailfinger]

On 24.04.2008 20:32, C. Scott Ananian wrote:
> 11. Bitfrost: initial activation security.
>
> Our deployment countries are very concerned with theft of XOs.  This
> item and the next address different mechanisms OLPC has designed to
> mitigate and manage this risk.
>
> "Initial activation security" means that an XO as delivered from the
> factory is a worthless brick.  It cannot be transformed into a
> functional machine without the use of an activation key, tied to the
> machine's serial number, which is generated by OLPC or the deployment
> country.  The goal of this feature is to deter theft-in-transit:
> activation keys and the XO hardware follow different paths to the
> target school, minimizing the value of the XO until it arrives in the
> hands of its child owner.
>
> Initial activation security is likely to be reasonably implementable
> on Sugar/Windows.  Mitch Bradley has been working on making Windows
> boot under OpenFirmware, and most of initial activation security is
> implemented in OpenFirmware's secure boot path.  The initial
> activation step currently involves booting a Linux kernel with a
> special ramdisk which validates activation leases and writes them to
> internal flash; this process could be used with only minor
> modifications to perform activation of Sugar/Windows machines.
>
>
> 12. Bitfrost: active and passive kill.
>
> Some countries want more aggressive anti-theft protection.  The terms
> of the GPL (as well as our own moral compasses) require us to allow
> the user to disable these mechanisms, but schoolkids who wish to keep
> them enabled gain some additional anti-theft protection.
>
> The theft-deterrence comes in two forms.  The first, passive kill,
> limits the lifetime of the initial activation lease (item #11).  The
> activation lease must be renewed periodically, or the machine reverts
> to the unactivated state.  A thief is guaranteed that a stolen machine
> will not be usable long.
>
> The vulnerability in this scheme is the real-time clock.  The XO
> hardware does not contain an hardware-protected clock (although we may
> be able to leverage firmware in the embedded controller to provide
> this), and so the burden of protecting the passive kill system from
> clock-reset attacks falls on the operating system.  It is rather
> difficult to secure Sugar/GNU/Linux against these attacks; it is
> unlikely that Sugar/Windows will ever be adequately secure.  (If we
> move to an EC-based implementation, then Sugar/Windows will require
> Windows kernel expertise in order to follow suit.)
>
> Active kill piggybacks on the update management system: when the XO
> performs a network transaction to look for an update, it may also be
> informed that it has been stolen, and immediately enter the
> deactivated state.  The obvious vulnerability is in the networking: an
> enterprising thief may conspire to prevent the XO from ever connecting
> to the theft-deterrence server.  A secondary vulnerability is in the
> daemon which periodically checks the theft-deterrence server:
> again, the burden falls on the operating system to protect that
> process from interference.  Again, this is difficult enough on
> Sugar/GNU/Linux; it is much more so on Sugar/Windows XP.
>
> For completeness, I will note that although passive and active kill
> theft-deterrence systems have been implemented on Sugar/GNU/Linux,
> only initial activation security has been deployed in the field.
> Passive and active kill systems entail large support costs which OLPC
> has chosen to date not to incur.
>   

AFAIK the hardware side of P_THEFT alias theft protection alias
activation security/kill functionality has not been implemented,
rendering all software efforts moot.

Unless the manufacturing details have changed since my last inquiry, I
can unlock ~4 XO machines per hour WITHOUT having a developer key. The
only thing I need are some really affordable tools. If someone else
disassembles the machines for me, I think unlocking 10 machines per hour
is well within the doable range.

For the record: I will not take orders for mass-unlocking unless
ownership is proven.


Regards,
Carl-Daniel