volunteer auditing/verification

by TOM ST DENIS on 2006-12-07 00:19:34

I've been asked to (and have) write some simple bios verification code
for the OLPC (laptop.org) project. Essentially, they wanted a simple
tool where they could sign a bios with various algorithms (in case one
dies in the future) and then verify it from the BIOS side (which has no
libc).

I've written the following code

http://libtomcrypt.org/cock.htm

Which is very rough [but functional] initial code that uses LTC and TFM
to perform the crypto (what else?).

The code fits in at around 70KB, and uses 64KB of heap so it's nice and
small (could be smaller I suppose but I do include both RSA and ECC,
Whirlpool and SHA512 in there, as well as an ASN1 library...)

Basically there are two pieces of code. The cli_tool can make keys,
signatures and verify the signatures. The bios_side is a rough stub
for what will be placed in the BIOS (with suitable use of -fPIC for
instance).

The signatures and key formats are ASN.1 encoded (to make porting this
to another library in the future possible if need be). The key format
is basically

olpckey ::= SEQUENCE {
rsaKey OCTET STRING,
eccKey OCTET STRING
}

Where rsaKey is a PKCS #1 RSAPublicKey or RSAPrivateKey. eccKey is a
LTC format public or private key (documented in the LTC user manual).
I basically encapsulated them in an OCTET STRING so there are two
levels of decoding required.

The signature format is

OLPCSignature ::= SEQUENCE {
RSAWhirlpoolSignature OCTET STRING,
RSASHA512Signature OCTET STRING,
ECCWhirlpoolSignature OCTET STRING,
ECCSHA512Signature OCTET STRING,
}

Where the RSA signatures are OCTET STRING encodings of PKCS #1 v2.1 PSS
signatures and the ECC are OCTET STRING encodings of X9.62 EC-DSA
sequences.

The keys are always RSA-2048 and ECC-521 (yes, I know those don't match
up in strength, but that's another longer story).

It may seem strange to use multiple algorithms, and yes, generally I'm
against that idea. The OLPC folk insisted, and since it doesn't really
expand the code, slow it down, or make it insecure I did as they asked.


All four signatures must be valid for the routine to indicate the
signature was valid. They plan on having multiple keys sign the BIOS
images and will have a threshold scheme to allow for revoked keys
(e.g., 2-out-of-3 keys valid == ok, but they have some tweaks in mind
for that...)

What we need

1. Someone to audit my heap code and look for ways to make it "go bad"
(tm) [see bios_side.c]

2. Someone to audit the LTC ASN.1 decoders to look for overruns or
ways to get invalid ASN1 packets passed it.

3. Someone to audit the LTC x9.62 EC-DSA generation/verification to
make sure it adheres to the standard

4. Someone to verify the LTC PKCS #1 v2.1 PSS generation/verification
to make sure it adheres to the standard.

The tarball [linked above] includes a copy of the CVS version of
LTC/TFM so you can inspect the ASN1/PK routines directly without having
to fetch them independently.

thanks,
Tom

ATfrOQSMgnvh8prGwqCl6ovjBgNCEnkFyNK03ycvi5U7dcCTVG4YwseRIPfa