LEGIC Prime is the older (1992) of the two high security RFID solutions offered by the Legic company (the other being Advant – released in 2004).
The Legic Prime is primarily used for high security access systems, but is also used in some payment situations, such as company cafeteria payments.
- Shrouded in a cloud of closed-ness and exclusivity
- Compared to MiFare: much harder to get cards and readers
- This secrecy is marketed as a security feature
Token structure is hierarchical: a token can only create objects with higher nesting level than its own. This allowed Legic to have resellers each permitted to write a nesting level for each customer and so forth.
Attacks were implemented using the Proxmark 3.
* Note: I’m not even going to try and take notes on the reverse engineering of the Legic protocol. Again, the slides and video are a good idea if you want more information.
When reverse engineering the protocol there were a lot of instances where things appeared to be returned in a strange order. This could possibly be used as an obfuscation to hinder decoding of the protocol.
By simply sending commands it is possible to read all segments, even the read protected areas. This code is now in the Proxmark SVN and should allow reading of data from the LEGIC Prime cards. It was also possible to overwrite data by simple brute-forcing the CRC for that data location, until the correct value was found (or calculated from previously held data – i.e. the UID).
This was all achieved without even looking at the silicon to reverse engineer the crypto functions.
“We did find something crypto looking, but too small to be cryptographically secure” – the state was found to be only 15bits, easily reversible, but not needed (brute-force). No key input –> not technically an encryption
A number of additional, and easier, attacks on the CRC functions where also discovered allowing you to spoof any card, including the master card (the card permitted to write other cards for a company).
The write command is also susceptible to the same CRC issue previously seen. This allows write to the card as desired.
By sniffing the communication between a card and reader it is possible to recreate the card in an emulated environment. When playing with the emulated card was found that Bytes 5 and 6 could only be decremented to prevent a user raising privileges. However with a blank card, this value is set to maximum and is possible to decrement it to the desired value.
- Byte 5 controls the token type (IAM, SAM, GAM)
- Byte 6 controls the stamp length (along with Byte 7)
- …
Data on the card is further obfuscated. The data is XORd with a secret value. This value turns out to be the CRC of the UID (which is stored on the card!).
Root problems
- No Keys (no key management, no card authentication, no reader authentication
- Spoofing, skimming
- Segments can be created out of thin air
- Master token can be created out of thin air
- No authorisation necessary for master token use, master token not inherently necessary for segment creation
Software released: Reader emulation
Not released: Card emulation, full protocol –> however reverse engineering is not hard, so upgrade ASAP
Please upgrade, but not to HID!
For more information :
Like this:
Like Loading...
Related
Cатсн²² (in)sесuяitу / ChrisJohnRiley 
Pingback: Tweets that mention 26C3: Legic Prime – Obscurity in Depth « Ramblings of the änal security guy -- Topsy.com