Prima di tutto voglio menzionare che assolutamente NON vuole implementare la mia crittografia in alcun modo. Stavo solo pensando a questo argomento e dopo alcune ricerche non ho trovato una buona soluzione.
Spero che ci sia una soluzione nota per questo problema che non riesco a trovare.
Supponendo che ci siano le tre seguenti parti:
- client : presuppone uno smartphone
- uC : un microcontroller collegato alla rete con un canale aggiuntivo non sicuro per il cliente
- server : alcuni server back-end witch hanno un database e fanno l'autenticazione del servizio web normale per entrambi, il client e l'uC
Come si può ottenere un'autenticazione del client contro il dispositivo uC utilizzando una password monouso secondo le seguenti ipotesi?
- Il client non deve essere in grado di autenticarsi prima che il server abbia dato il suo 'OK'. Assumi un processo di prenotazione / acquisto e l'uC esegue l'azione per consentire l'accesso
- I segreti possono essere condivisi tra il server < - > client e tra server < - > UC
- Il canale tra client e dispositivo uC deve essere assunto come non sicuro
- Un utente può avere più client che dovrebbero essere tutti in grado di autenticare
- Il dispositivo uC è solo uno dei tanti nel "campo", quindi il client dovrebbe essere in grado di autenticarsi con qualcuno di essi
- Client e server stanno comunicando tramite un'API REST
- Il dispositivo uC ha ovviamente un limitato potere di calcolo / archiviazione, ma utilizza anche un'API REST per comunicare con il server
- Tutte le comunicazioni API vengono eseguite tramite TLS
La seguente MSC sarebbe fattibile? La mia idea era sostanzialmente quella di utilizzare una catena hash per creare l'OTP. Ma poiché il client non deve conoscere il segreto per la creazione dell'hash, la generazione dell'OTP viene eseguita dal server.
+---------+ +---------+ +-----+
| client | | server | | uC |
+---------+ +---------+ +-----+
| | | ----------------\
| | |-| stores h^n(p) |
| | | | and n=1000 |
| | | |---------------|
| | ----------\ |
| |-| knows p | |
| | | and n | |
| | |---------| |
| | |
| request access | |
|---------------------->| |
| | ------------------\ |
| |-| check if access | |
| | | may be granted | |
| | |-----------------| |
| | |
| OTP = h^(n-1)(p) | |
|<----------------------| |
| | |
| OTP | |
|--------------------------------------------------------->|
| | | -----------------\
| | |-| grant access |
| | | | store OTP, n-- |
| | | |----------------|
| | |
| | access granted |
| | if n==0: create new h^1000(p) |
| |<---------------------------------|
| | ----------------------\ |
| |-| save granted access | |
| | | n-- | |
| | |---------------------| |
| | |
| | OK, h^1000(q) if needed |
| |--------------------------------->|
| | |
EDIT : ci ho pensato per altri cinque minuti, mi sono reso conto che questo non sarebbe un buon modo per risolvere questo problema, in quanto il server memorizza fondamentalmente il segreto e l'indice dell'hash- catena. Quindi, in caso di violazione dei dati, le OTP per le prossime n prove saranno note.
Potrebbe essere risolto solo memorizzando l'indice della catena di hash sul dispositivo uC e comunicandolo solo una volta al server? E.g se il client interroga l'UC per il suo indice corrente prima di richiedere l'accesso dal server?