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"


"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.

  • 1
    How do you know it is 128 bit? The public key you listed has 128 bytes, which is 1024 bits.
    – mikeazo
    Commented Oct 20, 2013 at 16:37
  • You're totally correct - I did mention I'm a crypto noob. So they're 1024 bit :)
    – swx
    Commented Oct 20, 2013 at 16:39
  • As indicated by mikeazo, $\;$ "128-bit" $\mapsto$ "1024-bit" $\:\:$ . $\;\;\;\;\;$
    – Ricky Demer
    Commented Oct 20, 2013 at 22:04
  • 1
    Not only is this off topic, but this is wrong for many reasons: one can not decipher with a public key; the public exponent is not given; the public key is expressed as a 128-byte string, but is not a valid public modulus when taken big-endian, because that would be a 1021-bit integer divisible by 2631907 (it might be correct when taken little-endian).
    – fgrieu
    Commented Oct 21, 2013 at 6:10
  • 3
    Your question might be better off on ReverseEngineering.SE as it is more about reverse engineering than the theory of crypto. I can migrate it there if you wish.
    – mikeazo
    Commented Oct 21, 2013 at 13:02

1 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 xedx (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.)

  • Hey, thans for the reply. According to the wikipedia article (and confirmed by what I am seeing in the code): fr.wikipedia.org/wiki/Vigik > A service's 'charging device' using RSA encryption using 768 or 1024 bit private keys allows badges to be issued to users. > Building access is controlled by adding the services' public key to the system.I'm not sure if it's encryption or signing - is there any way to tell? What I am sure of is that what I have here is the public key.
    – swx
    Commented Oct 20, 2013 at 18:34
  • Based on the extra information you've given, it looks like they're probably doing RSA signing. (Whether they're doing it correctly is another matter, of course.) In particular, it seems likely that the card contains either the private key, or (more likely) just a pre-signed token issued by the charging service, which the access-control device then verifies using the public key. Commented Oct 21, 2013 at 16:54
  • Thanks very much for the updates @Ilmari Karonen! So in theory, if I have the public key (from the access control unit) - and the the 1024bit signature on the card, I should, in theory, be able to verify the card signature w/ the public key - which would prove your theory? In this case, I guess it all comes full circle - how would I go about doing that exactly? Thanks again.
    – swx
    Commented Oct 21, 2013 at 18:19
  • You still don't have the public exponent as far as we can tell, right?
    – mikeazo
    Commented Oct 21, 2013 at 18:36
  • 1
    @swx: What you have is probably the modulus. (It could be the modulus and public exponent encoded some way into a single bitstring, but I doubt it.) The public exponent might be hardcoded into the RSA implementation; if you can't find something that looks like one, I'd suggest just trying the most common values (65537 = 0x10001 and 3). You'll also need to figure out how the modulus is encoded; it could be big- or little-endian or some funny mixed-endian format, or it might be something like BER. You can check by trying to factor it -- a valid RSA modulus should not have any small factors. Commented Oct 22, 2013 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.