Medicine transcription - volunteer auditing/verification

Author

volunteer auditing/verification

Tom St Denis

2006-12-06, 10:10 pm

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

Kathycarp

2006-12-06, 10:10 pm

You lost me at I've.........

--
Kathy
www.ambergriscaye.com/villadelsol
"Tom St Denis" <tomstdenis@gmail.com> wrote in message
news:0358247556.840132.36005@l81g2000cwl.googlegroups.com...
> 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

haggis

2006-12-06, 10:10 pm

LOL. It made me hear the old Steve Martin joke for a plumber's
convention--a prolonged bunch of gibberish and the punch line: "He said
"sprocket," not "socket!" (followed by uproarious laughter and
knee-slapping).

jeanne
(who thinks perhaps this guy's just not good at telling jokes) <G>

Kathycarp wrote:
> You lost me at I've.........
>