Sì in effetti hashare 7 byte non aiuta molto. Per questo ieri parlando con @g5pw suggerivo di aggiungere il salt_card.
Online suggeriscono di usare l’UID, ma resto sempre confuso all’idea che non sia forse meglio impostare noi un salt_card e lasciar perdere l’UID direttamente. La scheda è identificata da un valore che aggiungiamo noi così almeno brute force è escluso.
Per quanto riguarda l’ESP32, nemmeno io ho problemi con la piattaforma, e sicuramente avere la libreria per esp32 è utile non solo a noi! Rispetto all’orange pi è sicuramente più portabile.
Forse è meglio iniziare più ad alto livello, e poi implementare i dettagli pensando a tutta l’infrastruttura che si vuole supportare.
Ad esempio:
Vogliamo usare un server esterno centralizzato per la decisione di acesso?
Allora il circuito deve essere il più trasparente possibile a questo servizio (si occupa solo di stabilire una canale sicuro fra il tag e il server)
Vogliamo qualcosa che decida lui autonomamente secondo delle regole interne (aggiornate periodicamente da un server centrale). Quindi si complica il deployment e l’accentramento delle regole e audit.
Secondo me the way to go è andare con la proposta 3, scegliendo K0 := KDF(UID,<pre_shared_secret>).
Per quanto riguarda la generazione del DB, io ometterei K{S,P}_c e userei solo TLS auth, tanto il database dobbiamo tenerlo in chiaro da qualche parte, quindi avere anche chiavi asimmetriche per i lettori mi sembra un overkill.
Abbiamo il PN532 nella porta, che comunica con l’interno via un converter RS232. Abbiamo verificato che l’apertura della porta via relay funziona, entro breve programmo l’esp32 e dovremmo avere una base da cui partire!
