Understanding hardware extracted keys

Question

I'm a crypto newbie, but have been working on card-access systems that encrypt the card data with 128-bit RSA.

I have an example (from a card) of 1024 bits of encrypted data. I also have the public key (1024 bits), which is (rather curiously) placed into the access-control hardware. I'm 100% sure it's a public (not a private) key.

First attempts with using the key with OpenSSL with the binary key fail:

➤ openssl rsautl -decrypt -in ptt.enc.key -inkey ptt.pub.key -out ptt.dec.hex
unable to load Private Key
➤ 11636:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:648:Expecting: ANY PRIVATE KEY

I'm aware that I need to probably format / prep the key, but I'm not sure how.

Any ideas?

Edit For what it's worth: The public key is:

15 77 D0 29 87 C6 3A 95 B5 1A E1 49 43 08 34 AE AF 3F 2E 0F 4C F8 C6 88 7A C6 C8 D7 32 D7 94 82 60 4F C1 8D A7 7A 9C C1 F5 4D 80 63 EA E6 E4 2A 41 B2 E0 4D 16 63 85 6D 76 0E AB EC CF B7 83 BA E1 D4 3E 1E 02 C5 01 1E 82 3B 24 F2 91 8F 98 A4 96 2A 87 5D 0D F9 4F 80 98 A1 A3 0D C9 41 30 3F 98 AB A1 9E 6F 99 65 97 ED AD 7F 03 CA B9 15 ED 4B 58 B7 BA AD 28 C0 B6 75 93 CD FC CB 53 99 AB

An encrypted card value is:

8F 04 8D E0 83 7F 29 C8 03 54 D1 B5 E3 03 27 4E 3F C5 8D 79 75 D6 A1 FE 3B 67 F1 43 99 65 CC EE B1 A8 55 BA E8 3D A7 81 75 FD 2E 86 B3 A6 C8 A0 4E 0D 77 1E C3 C0 AE 27 DA 06 3D 8F A5 CC E0 32 3D 65 60 E9 86 A2 65 E2 BB D3 B9 37 4E A6 BF 91 89 02 C5 26 E0 AF FD A8 82 23 68 38 4E 26 51 44 52 D9 B6 CA 6E 84 0A 9D 6C FA BE 85 D3 22 DF 57 61 B9 A8 21 0B A4 6D 89 12 4A 64 25 83 12 60 3D

The overall protection works like this: External services can have access to buildings - but each individual access is time limited, to prevent abuse. Cards must be refreshed every day or so.

According to the system documentation:

"Building access is controlled by adding the services' public key to the building's device"

And:

"A service's 'charging device' using RSA encryption using 768 or 1024 bit private keys allows badges to be issued to users on a daily basis"

I agree - this seems to be the inverse of an asynchronous key system (distributing the public key, and then using the private key for encryption) - so perhaps they're doing something different (RSA signing?) - this is what I'm trying to determine.

This is corroborated within the hardware code that I'm seeing:

$PubKey = "x31353737443032393837433633413935423531414531343934333038333441454146334632453046344346384336383837414336433844373332443739343832363034464331384441373741394343314635344438303633454145364534324134314232453034443136363338353644373630454142454343464237383342414531443433453145303243353031314538323342323446323931384639384134393632413837354430444639344638303938413141333044433934313330334639384142413139453646393936353937454441443746303343414239313545443442353842374241414432384330423637353933434446434342353339394142"

Hopefully this edit will provide some clarity on the whole situation - I appreciate your insight and assistance.

Answer 1

An RSA public key consists of two things: the modulus m (a product of two large primes p and q) and the public exponent e (a small and often fixed number, commonly 3 or 65537).

An RSA private key consists of the same modulus m as in the public key and the private exponent d, a number chosen such that x^ed ≡ x (mod m). Typically, d will be about the same size as m or slightly shorter. (Alternatively, it's possible to instead store the primes p and q, from which, together with e, the modulus m and the private exponent d may be calculated.)

Anyway, your 1024-bit number looks like it might be the modulus (although, if so, it certainly shouldn't have any small factors). Are you sure there isn't another number stored in the hardware that could be the private exponent?

Also, are you sure the device is actually doing RSA encryption, and not, say, RSA signing, which looks superficially like "encrypting with the private key" (although the the details of the padding schemes needed to make the two operations secure differ considerably)?

---

Edit: My French is kind of rusty, but based on the extra information you've given and what I could gather from the Vigik site at a glance, it looks like what they're doing is probably something like this:

• The charging service holds the private key, while the access control device has the corresponding public key. The card probably doesn't hold either key, and may or may not actually do any crypto at all.

• When the card is charged, the charging service creates a message stating that this particular card is authorized access to particular locations until a particular time. It then signs this message using the private key and sends the signed message to the card.

• When the card is used to request access, it transmits the signed message to the access control device, which verifies that the authorization is valid for the location, has not expired, and that the signature is correct.

At least, this is more or less how I would design a system like this. One advantage of this design is that neither the card nor the access control device need to know the private key, so it cannot be compromised even if either of them is stolen and analyzed. (The charging service does need the private key, but presumably it can be secured better than the cards and access control devices, possibly even by doing the actual signing on a remote server.) It also doesn't require the card itself to do any crypto, which makes them much easier and cheaper to implement.

(Actually, though, if I were designing such a system and had a card that could do RSA signing, I'd also give each card its own private key, include the corresponding public key in the authorization message, and have the access control device request a zero-knowledge proof that the card really knows the private key it claims to have. This would make the cards truly uncloneable, even temporarily, without some serious reverse engineering effort to extract the key.)