Additional security
Closed this issue · 2 comments
I have been almost paranoid about the enrolment of new blank fobs. If someone was to fake a card, they could get the keys for a whole site.
This is an inherent risk with the DESFire. It was a bit theoretical, but with things like a flipper zero, it becomes a lot easier. Indeed I have put in a feature request to emulate a new blank DESFire EV1 and show keys - which seems to fit with a pen-test device.
But I had an idea of one small improvement, which, with a bit of care, could be backwards compatible.
At present the AID used has a key used for the whole site. But what if the key was actually the card UID encrypted using the site key. We get the UID up front and so can make the keys to use on the fly in the reader.
It would mean that if you emulate a card you get keys, but only keys for that UID. The same key would not work for another UID, and you could not enrol an existing UID.
It is a risk still, as the key on the UID you have made would allow you to change the underlying security settings on that fob, and hope to be quick enough to allow access before it was corrected by the system. Indeed, we could log such changes when something other than just expiry refresh as added security.
But you would not get keys allowing you to make other card UIDs, or to access other cards to make changes on other cards.
I am not sure how much it is worth while doing this as the compromise even on one card is enough to allow some access.
But it is such a simple change that it seems like it may be worth considering - and as I say, in a backwards compatible way.
It probably means, at the same time, implementing a key roll over in the linux side. The readers already have key roll over logic if sent new and old keys. The trick would be to add a flag saying the keys are "indirect", and we can then roll over a site from current to new logic in controlled ways.
I think this will only work if we can make a way to make it backwards compatible, and auto update fobs.