In 2020 Gallagher issued a security alert that their ‘default site key’ for Desfire cards had been compromised and users should ensure they use a unique site specific key instead.
For non-nefarious purposes and to satisfy an itch after much googling, does anybody know how I might find out what the Gallagher default site key is?
This link:
Says:
“Finally, the default application key is the result of diversifiying the bytes 0x03 0x00 0x00 0x00.”
Not sure if that’s helpful, or what it means
That is very helpful. I’ve been looking everywhere for that info and thought I had read that page multiple times but absolutely missed that bit.
Thanks.
Can you elaborate what you’re able to with that? Still a noob lol
At this stage I’m very much a noob as well, so there isn’t a lot I can do with this info at the moment.
My workplace uses Gallagher access systems and mainly uses Mifare Classic cards, which I’ve managed to clone to my FlexM1.
All new staff ID cards issued are Mifare Desfire. I can only assume they are slowly phasing out the Mifare Classics and one day will turn off the backwards compatibility of the Mifare Classics.
To stay ahead of the game I want to get hold of some Desfire cards and have a play with them to see if I can write the Gallagher Card Access Numbers onto them and get them to work within the system.
As the current Mifare Classic cards have zero unique keys on them and the system doesn’t care about UID’s I am assuming that work will be using the Desfire default site key, which will hopefully allow me to figure out a way to add the Gallagher info needed to a Desfire card for it to work within the system.
But, it will take me a while to figure out. 2 months ago I couldn’t read hexadecimal or binary and didn’t know a bit from a byte. I decoded the Gallagher access details by hand, with a pen and paper.
2 weeks ago I used Linux for the first time. Now I have a Proxmark3 set up and have my work ID cloned to my implant. And what took me an hour by pen and paper can be done in seconds.
Now I’m learning XOR’ing and polynomials, it’s all a giant learning curve but I like figuring shit out.
Go get it dude! Great stuff! Keep up the hard work
First of all, congrats on your journey! and that seems like a great personal advancement already!
Now…
If your head of security is worth it’s salt…
The only (decent) reason to change into Desfire is to leverage at least it’s encryption capabilities.
If I’m thinking of the most basic possible desfire access control, you would have one “site key”, yes, but that key will never be passed into the cards themselves.
What the system does with it is…
When you present a card to be added into the system, that core key is used in conjunction with the card’s UID (and/or more stuff) to generate a secret passphrase, stored onto the card.
The “site key” is used then just to erase/modify said passphrase. So… admin only, never access.
When the card is presented against a reader, then the reader would query the UID and/or type of card, then if it’s acceptable, it should ask the Desfire to validate with an encrypted passphrase.
This would be just a very basic system, and not only there is more to leverage from Desfire cards, but there are also some more security practices to be used there, but this is enough to compare against the Mifare Classic…
On the Mifare Classic you cannot ask the card to validate a specific encrypted passphrase. Either you validate against UID/secret, or you don’t.
This distinction makes it so that, on Desfires:
That said… This is all assuming your work’s Security guy actually knows what it does.
Because I’ve seen more places migrating into Desfire, but continuing to read only the UID, than I’ve seen places actually leveraging any DF security features. 
Thanks for all that info.
Just to clarify, does that mean any system that uses DF generates the passphrase using the UID and because there are no magic DF cards the UID can’t be changed and therefore DF can’t be cloned?
With the current Mifare Classic system being used they are not using the UID. They are using the Gallagher Card Credentials stored in sectors 14 & 15 with no unique keys in sector 0 or any other sector. Cloning a card takes about 2 secs using my phone.
I was hoping to get hold of a DF card and write some already known (my ID) Gallagher Card Credentials into one of the applications and hope the system would read it.
Not really. That would just be the easiest way to do that.
Another equally easy implementation would be to assign the user an internal name and database ID, stored outside of the card, and use that to identify the user and generate the passphrase.
You can clone the UID into any “magic” card with the correct UID length.
But that would only work if the system in question uses only UID and don’t even check for card type.
The reason why a DF can’t be clone goes beyond the UID.
You would need not only to be able to find a magic DF card, but would also be able to have access to the application Key in order to read the encrypted block of information relating to said application and clone it to the new card.
(there is more than that in play, but in a nutshell, that’s it).
Since the application key should only be found on the application admin side, you wouldn’t find it by sniffing neither the card nor the terminals.
If they are migrating from Classic to DF, I would expect (hope?) that they would also be upgrading to a more robust security practice.
But let’s assume they would just be tossing some credentials into blocks 14 & 15…
Even then, this scenario tells me they would be going lazy and probably getting a ready made script from someone else (there are quite a few available).
Those scripts take into consideration that the interface between reader and card is slightly different based on which card it is.
i.e. the way a reader would ask for a Mifare Classic “what’s the data on your Sector X” could be slightly different from how it would ask a DF “what’s the data on your Sector X”.
So the system should first query the card about “what type of card are you?” and then it knows how to interface properly with the card.
If you have 2 systems being implemented, that’s most likely to be the case, and it makes cloning cross cards very challenging for any system which is not UID based.