[perpass] Traitor Keys and certified hardware

Phillip Hallam-Baker <hallam@gmail.com> Mon, 18 November 2013 17:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA8011E8230 for <perpass@ietfa.amsl.com>; Mon, 18 Nov 2013 09:58:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.195
X-Spam-Level:
X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2gyCg0ynqF6 for <perpass@ietfa.amsl.com>; Mon, 18 Nov 2013 09:58:10 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8D11E81BE for <perpass@ietf.org>; Mon, 18 Nov 2013 09:53:08 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id u14so1748220lbd.27 for <perpass@ietf.org>; Mon, 18 Nov 2013 09:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jjiKhxiSx9nB9v3/RiOS8JgIjlLT5isbznXLbKWuwhw=; b=0evTj3gRlIlBD9wgtX463j6YH2iPoV+drQMsWKNFZj4Y6L00IvbpjqKLiztIaihW8M Uz3ioPtIV4irL5KgSYjFiKLX3bIZF5BHMREGRVS2mwln3AJUbqJ+/sXr6Y0ocQ175Qm+ v7tXAwSduu+FNPBKe+LM/Fc840vDKwRhjFEsMA4n1N3OKKqLpLYbAiGtZuQoSOz/VCb7 4e2AVoM4XaZFBrZFMZ2LkP2khq8Fa9+QQBUqPBnD4mZodP4HhYOKwIekw9/Qik02BIPM nIYwVDSRcrFsBIEqgkjN1GmtKTF6MAL9uQDG5FNo9WoaEjWig6HhHM4uGesUu1JUfnxB XFlw==
MIME-Version: 1.0
X-Received: by 10.112.168.170 with SMTP id zx10mr14445900lbb.0.1384797183902; Mon, 18 Nov 2013 09:53:03 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Mon, 18 Nov 2013 09:53:03 -0800 (PST)
Date: Mon, 18 Nov 2013 12:53:03 -0500
Message-ID: <CAMm+Lwjp3Nv5sv6fC2zvrKv7PY1dv2xbbkNGA8CT+woBhXPhzg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: perpass <perpass@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c23c883b8b4c04eb77383c"
Subject: [perpass] Traitor Keys and certified hardware
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2013 17:58:23 -0000

I have been thinking through the possible origins of the NIST/NSA elliptic
curve random number generator with a backdoor. My first reaction was 'what
were they thinking'. Followed by essentially the same conclusion as
everyone else.

But coming back to the problem I realized this morning that we might be
missing something in Dual_EC_DRBG. There is actually an advantage to the
scheme, provided that you generate your own curve and keep it safe.

Let us suppose for the sake of argument that Dual_EC_DRBG was originally
designed for the sole purpose of protecting US government secrets better
and that there either was never an intention to exploit the backdoor or
that was a change that occurred subsequently. What advantage would that
give?

If the generator is seeded from a simple static seed, the main effect of
having a backdoor in the randomness prep is that it makes the process
deterministic. An external auditor can use the backdoor to recover the seed
and then run the device for an extended period to see if the behavior of
the device is fully consistent with that seed choice.

If there is a side channel in the purported DRNG, the party who knows the
backdoor can check it very quickly.

If the generator seeding is dynamic, acquiring >X bits of new seed before
outputting X new bits of output, the backdoor doesn't help. But that would
mean it wasn't a DRNG.


Using such a scheme if the potential attacker knows the backdoor key is
obviously bad. But within the narrow requirements of the NIST
specification, the scheme does have clear advantages for the government. It
means that they can buy commodity hardware and quickly check to see if it
has been compromised during manufacture.

So the real lesson here might be that people should use Dual_EC_DRBG but
with hardware that allows end users to choose their own curves. Which is
incidentally what NIST actually advised.


So now lets turn to the idea of some sort of open source crypto hardware
platform, how might we apply this scheme?

Lets imagine for the sake of argument that we are using Raspberry Pi
computers which are a commodity computer that is (1) cheap, (2) boots from
an SD card (no BIOS), (3) supports a mouse, keyboard and HDMI display.
Cheap matters here because several of these machines are going to be
burners (literally).

The device does not have tempest shielding etc. But I am assuming here that
we are taking other precautions to prevent that sort of attack. It is easy
enough to build a Faraday cage you can sit in.


We start the process with a collection of commodity SD cards bought from a
randomly chosen retail vendor and an ISO image of our favored stripped down
O/S. We have two separate applications that we would run.

1) The key manager to audit.
2) The curve generation and audit code.

We install the programs on separate ISO images on separate machines. Then
we write the images out, fingerprint them and publish the full sources, etc.

We then boot the curve generation machine and generate a curve, we give the
curve to the key manager machine, run it through the full suite of tests
and check that the outputs exactly match what they are supposed to using
the backdoor to the curves. the key manager device is going to dump out a
statement giving the curves used each time as part of its output. For
example, pass the hash of the curve spec in the upper bits of the RSA
modulus using Moti Young's technique.

The whole process is precisely deterministic and therefore auditable. The
program does not know if it is being run as a test or for real. So a device
that defects only one in ten or one in a thousand times can be caught.

This is the reason I don't want to switch from ASN.1 for certs despite it
being such a pain, the distinguished encoding is good for exactly one thing
and that is eliminating side channels.


Before we can use the device we have to establish a trustworthy set of
curves. Fortunately this is something that only needs to be done once,
though if people doubt the trustworthiness of the curves used they could
follow the script and repeat the process.

To do this properly we need a ceremony.

One of the functions of a ceremony is to ensure that things are done
repeatably. Bronowski's Ascent of Man has an example of a Samurai sword
being made which is a formal ceremony.

The two requirements would be to ensure that the seeds used for generating
the curve are completely random and that all physical hardware that has
touched them is destroyed after use.

The Raspberry Pi is low power enough to run on batteries. A steel box for a
Faraday Cage is simple enough for blocking E-M radiation. Can add in a
noise generator

Turns out that thermite is not quite hot enough to melt silicon. But
Oxy-Acetelyne is.

The trickiest problem with disposal is likely going to be disposing of the
battery safely.

-- 
Website: http://hallambaker.com/