[148996] in cryptography@c2.net mail archive
Re: [Cryptography] Dumb idea: open-source hardware USB key for
daemon@ATHENA.MIT.EDU (Owen Shepherd)
Sat Jan 11 18:32:45 2014
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAAt2M1_91wHYfku=_7QLnXAoP3zbuddYkhKHG_OuQLkULcGsbQ@mail.gmail.com>
Date: Sat, 11 Jan 2014 23:29:48 +0000
From: Owen Shepherd <owen.shepherd@e43.eu>
To: Natanael <natanael.l@gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>,
Bill Cox <waywardgeek@gmail.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============7007824964685382317==
Content-Type: multipart/alternative; boundary=001a11c39536f7caf404efba37aa
--001a11c39536f7caf404efba37aa
Content-Type: text/plain; charset=UTF-8
My thoughts:
- An FPGA is a bad idea. You need an external ROM to contain the
configuration data. How often are you going to verify the contents of that
ROM? (Answer: probably never). There is no way to read protect that ROM
- Smart card chips would be ideal but tend towards confidential specs,
and additionally would seem to be obvious targets for a back door?
- A commercial off the shelf micro seems like a viable option.
Why do I say this?
- The flash is inside. No easy lines to probe.
- Most have EFuse bits which can be set which don't let you read or
write the device without doing a full erase
- You can get them with large flash. 512kB flash is enough for both the
code and a sizable collection of public/private key pairs
- A *lot* less gates for someone to fiddle with than an FPGA. An ARM
Cortex-M-style MCU is intrinsically no less safe than an FPGA (Note that
there is no complicated microcode ROM to subvert, no System Management Mode
to hide in, no motherboard embedded controller to replace the code on, etc)
Proposed layers of protection:
- The manufacturer's provided anti-readout functionality. This is
probably the weakest
- Once the board has been burned, encapsulate it in epoxy to make access
to the device pins difficult. This just leaves the USB pins as an attack
avenue
- Key encryption
Key encryption: Use some standard cryptographic algorithm (AES, Salsa/20,
whatever) to encrypt the keys with the user's PIN/key/password.
Side channel protection: Main one is power. Stick a resistance in series
with the power line, and a sizable capacitance after it? These micros are
pretty power efficient, that should provide quite sizable decoupling
between the internal power rails and external. Of course have all your high
frequency bypassing like normal.
Precautions to be taken by user: Don't plug into strange computers?
Threats:
- Theft by non sophisticated adversary. Mitigation: PIN/Key code
- Theft by sophisticated adversary (e.g. NSA). Mitigation: Encrypt the
secrets with the PIN
- Modification by a sophisticated adversary. Primary Mitigation:
Potting. Hardware Protection. This certainly is the strongest, though least
likely threat model. Its' difficult to find a way to protect from this one
in general; a smart card chip would help, though based upon disassembly by
people like Flylogic Engineering they don't buy you much.
- Reading of memory from a live instance by an adversary. Mitigation:
Don't keep keys in RAM unless you're doing a cryptographic operation. Have
relatively short timeouts after which PIN re-entry is required, preferably
non-resettable.
Could implement some form of "tamper detect" system, e.g fragile wires
embedded over the chip which would provide indication of case tampering.
Issues with these though (e.g. accidental shorting during assembly).
Determined adversary is liable to be able to counter this.
- Firmware bugs: Authenticated firmware update mechanism (i.e. require
the PIN to be entered to authorize new firmware download, validate have
user validate signature before letting it run? This is trickiest, because
of confined flash space.
Maximize simplicity of firmware. Obviously this is somewhat difficult in
the face of USB. Using an off-chip USB controller avoids that issue, in
exchange for the other that now the driver and user interface situation is
made more complex (USB serial ports for one are seriously ugly)
Other features: At a minimum a keypad, a display. This is not going to be
compact.
Potentially: (Micro)SD card slot so can function as encrypted flash drive?
Some form of analog RNG built on PCB? Preferably in addition to some form
of hardware RNG inside the chip (though chip manufacturers are notoriously
cagey about how good their entropy generators are, it can't hurt to mix in
extra slush)
Owen Shepherd
http://owenshepherd.net | owen.shepherd@e43.eu
On 10 January 2014 23:57, Natanael <natanael.l@gmail.com> wrote:
> Den 11 jan 2014 00:23 skrev "Bill Cox" <waywardgeek@gmail.com>:
>
> >
> > I've been noodling the idea of a USB stick designed in a way that we
> > can trust the crypto that goes on there. It's a hard problem, but
> > there seems to be some guidelines that could help:
> >
> > - Open source hardware - schematics and everything including board
> > layout need to be free
> > - No ICs that could be compromised. Any CPU would have to be a
> > soft-core in an FPGA, with an open-source design
> > - FPGA configuration memory both readable and writable over a JTAG port
> > - External flash program memory also read/writeable through JTAG
> > - Reasonable hardware RNG where every node in the circuit can be probed
> > - Signal isolation from the PC: solid state relays would swap a simple
> > memory back and forth between the PC side and USB stick side. Maybe
> > power draw should be randomized to obscure any processing going on.
> > RF shielding should cover the USB stick. No other communication
> > should be possible. This is similar to an air gap.
> > - A community supported audit trail verifying produced USB keys are
> secure
> >
> > The idea still has issues. Where would I be able to store secret keys
> > securely such that an attacker who stole my USB stick could not
> > recover it? Anyway, it's just a fun idea. I'd love to have such a
> > device in my pocket. There's a lot of applications I can think of
> > that could benefit from it, from electronic voting to
> > microtransactions. As one security expert once said in an
> > electronic-voting discussion I followed, no machine ever connected to
> > the Internet has proven secure. Could we make such a beast? I
> > probably don't really have time to work on it, but if a group were
> > building it, I'd participate.
>
> You just put your trust in that the FPGA isn't backdoored. There's been
> backdoored FPGAs before, plenty of times. Secure storage of keys require
> custom hardware as well, an FPGA is just a computational device in itself.
> You need a smartcard or TPM style chip.
>
> Maybe you want an open source HSM?
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--001a11c39536f7caf404efba37aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My thoughts:<br><br><div class=3D"gmail_extra"><ul><li>An =
FPGA is a bad idea. You need an external ROM to contain the configuration d=
ata. How often are you going to verify the contents of that ROM? (Answer: p=
robably never). There is no way to read protect that ROM</li>
<li>Smart card chips would be ideal but tend towards confidential specs, an=
d additionally would seem to be obvious targets for a back door?</li><li>A =
commercial off the shelf micro seems like a viable option.</li></ul><p>
Why do I say this?</p><ul><li>The flash is inside. No easy lines to probe.<=
/li><li>Most have EFuse bits which can be set which don't let you read =
or write the device without doing a full erase</li><li>You can get them wit=
h large flash. 512kB flash is enough for both the code and a sizable collec=
tion of public/private key pairs</li>
<li>A *lot* less gates for someone to fiddle with than an FPGA. An ARM Cort=
ex-M-style MCU is intrinsically no less safe than an FPGA (Note that there =
is no complicated microcode ROM to subvert, no System Management Mode to hi=
de in, no motherboard embedded controller to replace the code on, etc)<br>
</li></ul><p>Proposed layers of protection:</p><ul><li>The manufacturer'=
;s provided anti-readout functionality. This is probably the weakest</li><l=
i>Once the board has been burned, encapsulate it in epoxy to make access to=
the device pins difficult. This just leaves the USB pins as an attack aven=
ue</li>
<li>Key encryption</li></ul><p>Key encryption: Use some standard cryptograp=
hic algorithm (AES, Salsa/20, whatever) to encrypt the keys with the user&#=
39;s PIN/key/password.</p><p>Side channel protection: Main one is power. St=
ick a resistance in series with the power line, and a sizable capacitance a=
fter it? These micros are pretty power efficient, that should provide quite=
sizable decoupling between the internal power rails and external. Of cours=
e have all your high frequency bypassing like normal.</p>
<p>Precautions to be taken by user: Don't plug into strange computers?<=
br></p><p>Threats:</p><ul><li>Theft by non sophisticated adversary. Mitigat=
ion: PIN/Key code</li><li>Theft by sophisticated adversary (e.g. NSA). Miti=
gation: Encrypt the secrets with the PIN</li>
<li>Modification by a sophisticated adversary. Primary Mitigation: Potting.=
Hardware Protection. This certainly is the strongest, though least likely =
threat model. Its' difficult to find a way to protect from this one in =
general; a smart card chip would help, though based upon disassembly by peo=
ple like Flylogic Engineering they don't buy you much.</li>
<li>Reading of memory from a live instance by an adversary. Mitigation: Don=
't keep keys in RAM unless you're doing a cryptographic operation. =
Have relatively short timeouts after which PIN re-entry is required, prefer=
ably non-resettable. <br>
<br>Could implement some form of "tamper detect" system, e.g frag=
ile wires embedded over the chip which would provide indication of case tam=
pering. Issues with these though (e.g. accidental shorting during assembly)=
. Determined adversary is liable to be able to counter this.<br>
</li><li>Firmware bugs: Authenticated firmware update mechanism (i.e. requi=
re the PIN to be entered to authorize new firmware download, validate have =
user validate signature before letting it run? This is trickiest, because o=
f confined flash space. <br>
Maximize simplicity of firmware. Obviously this is somewhat difficult in th=
e face of USB. Using an off-chip USB controller avoids that issue, in excha=
nge for the other that now the driver and user interface situation is made =
more complex (USB serial ports for one are seriously ugly)<br>
</li></ul><p>Other features: At a minimum a keypad, a display. This is not =
going to be compact.</p><p>Potentially: (Micro)SD card slot so can function=
as encrypted flash drive?</p><p>Some form of analog RNG built on PCB? Pref=
erably in addition to some form of hardware RNG inside the chip (though chi=
p manufacturers are notoriously cagey about how good their entropy generato=
rs are, it can't hurt to mix in extra slush)</p>
<p><br></p><div><div dir=3D"ltr"><div>Owen Shepherd<br></div><a href=3D"htt=
p://owenshepherd.net" target=3D"_blank">http://owenshepherd.net</a> | <a hr=
ef=3D"mailto:owen.shepherd@e43.eu" target=3D"_blank">owen.shepherd@e43.eu</=
a><br>
</div></div>
<br><br><div class=3D"gmail_quote">On 10 January 2014 23:57, Natanael <span=
dir=3D"ltr"><<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank">=
natanael.l@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<p dir=3D"ltr">Den 11 jan 2014 00:23 skrev "Bill Cox" <<a href=
=3D"mailto:waywardgeek@gmail.com" target=3D"_blank">waywardgeek@gmail.com</=
a>>:</p><div><div class=3D"h5"><br>
><br>
> I've been noodling the idea of a USB stick designed in a way that =
we<br>
> can trust the crypto that goes on there. =C2=A0It's a hard problem=
, but<br>
> there seems to be some guidelines that could help:<br>
><br>
> - Open source hardware - schematics and everything including board<br>
> layout need to be free<br>
> - No ICs that could be compromised. =C2=A0Any CPU would have to be a<b=
r>
> soft-core in an FPGA, with an open-source design<br>
> - FPGA configuration memory both readable and writable over a JTAG por=
t<br>
> - External flash program memory also read/writeable through JTAG<br>
> - Reasonable hardware RNG where every node in the circuit can be probe=
d<br>
> - Signal isolation from the PC: solid state relays would swap a simple=
<br>
> memory back and forth between the PC side and USB stick side. =C2=A0Ma=
ybe<br>
> power draw should be randomized to obscure any processing going on.<br=
>
> RF shielding should cover the USB stick. =C2=A0No other communication<=
br>
> should be possible. =C2=A0This is similar to an air gap.<br>
> - A community supported audit trail verifying produced USB keys are se=
cure<br>
><br>
> The idea still has issues. =C2=A0Where would I be able to store secret=
keys<br>
> securely such that an attacker who stole my USB stick could not<br>
> recover it? =C2=A0Anyway, it's just a fun idea. =C2=A0I'd love=
to have such a<br>
> device in my pocket. =C2=A0There's a lot of applications I can thi=
nk of<br>
> that could benefit from it, from electronic voting to<br>
> microtransactions. =C2=A0As one security expert once said in an<br>
> electronic-voting discussion I followed, no machine ever connected to<=
br>
> the Internet has proven secure. =C2=A0Could we make such a beast? =C2=
=A0I<br>
> probably don't really have time to work on it, but if a group were=
<br>
> building it, I'd participate.</div></div><p></p>
<p dir=3D"ltr">You just put your trust in that the FPGA isn't backdoore=
d. There's been backdoored FPGAs before, plenty of times. Secure storag=
e of keys require custom hardware as well, an FPGA is just a computational =
device in itself. You need a smartcard or TPM style chip. </p>
<p dir=3D"ltr">Maybe you want an open source HSM? </p>
<br>_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br></blo=
ckquote></div><br></div></div>
--001a11c39536f7caf404efba37aa--
--===============7007824964685382317==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============7007824964685382317==--
