Ci sono due punti principali per le tue situazioni.
1. Il lucchetto dovrebbe sapere come sbloccarsi?
Esistono fondamentalmente due tipi di sistemi di "firma" e solo uno di questi è davvero una firma . Nella tua situazione, il server invierà al dispositivo una sorta di token che il dispositivo verificherà . Quindi la domanda è: è un problema se il dispositivo avesse il potere tecnico di produrre un token valido? O le cose dovrebbero essere tali che il dispositivo non contenga nulla che gli consenta di creare nuovi token del genere?
Nel primo caso, puoi lavorare con un MAC , e HMAC / SHA-256 non è una cattiva scelta per quello. Tuttavia, ciò significa che il dispositivo e il server condividono alcune chiavi segrete, utilizzate sia per produrre che per verificare i token di sblocco. Se ci sono diversi dispositivi, ognuno di essi dovrebbe avere la propria chiave specifica del dispositivo, e il server dovrebbe quindi conoscere tutte le chiavi del dispositivo - altrimenti, l'estrazione di un dispositivo consentirebbe a un utente malintenzionato di apprendere abbastanza da sbloccare tutti gli altri dispositivi.
In quest'ultimo caso, il server ha una coppia di chiavi asimmetriche; i token di sblocco sono firmati con la chiave privata del server e i token di verifica dei dispositivi con la chiave pubblica del server. RSA è un noto algoritmo di firma digitale; la parte di verifica è poco costosa e quindi può essere eseguita dalla maggior parte dei dispositivi, anche dispositivi a potenza limitata.
2. Che dire di attacchi di riproduzione ?
Un "attacco di replay" è, nel tuo caso, quando un utente malintenzionato osserva un token di sblocco e lo invia di nuovo in un secondo momento. Esistono diversi modi per evitare tali problemi, ma implicano tutti una sorta di capacità aggiuntiva sul dispositivo:
-
Token a tempo limitato. Il token include una data di emissione e il dispositivo non accetta un token che è "troppo vecchio". Questo metodo richiede che il dispositivo abbia un clock incorporato ragionevolmente preciso.
-
Rilevamento duplicato. Il dispositivo ricorda i token di sblocco visti in precedenza e si rifiuta di agire su un token che ha già visto. Ciò richiede una sorta di memoria che non può essere ripristinata.
-
Nonces . Il dispositivo emette innanzitutto un valore casuale e si aspetta che il token di sblocco contenga una copia di quel valore specifico. Ciò rende il protocollo più complesso e richiede che il dispositivo sia in grado di emettere dati e ricevere token. Questo non si adatta bene a tutte le situazioni; ad esempio, se il dispositivo è una serratura, con una tastiera, e l'utente contatta il server attraverso il suo smartphone. In genere, il dispositivo necessiterebbe di un piccolo schermo LCD per visualizzare il suo nonce.
Puoi prendere in considerazione HOTP : questo è un protocollo basato su MAC, quindi con una chiave condivisa tra "server" "e" dispositivo ". Sia il server che il dispositivo ricordano solo un breve valore del contatore (ad esempio, 32 bit) e questo è sufficiente per proteggersi dagli attacchi di replay. La comunicazione è a senso unico (il dispositivo non ha bisogno di emettere nulla). Questo protocollo (o qualsiasi altra variante simile) è quello che viene utilizzato per sbloccare l'auto: l'auto è il "dispositivo" e il telecomando collegato al portachiavi è il "server".
Tutto quanto sopra riguarda il token inviato da server a dispositivo. Naturalmente, il server non dovrebbe produrre il token a meno che non abbia la certezza che è token all'utente giusto (il proprietario del dispositivo). Hai quindi bisogno di autenticazione che, in pratica, significherà SSL. Consentire all'utente di aprire una connessione SSL con il server (ad esempio HTTPS) e autenticarsi con il server. Il livello SSL si prenderà cura dell'integrità e della crittografia in modo da non dover crittografare il token stesso. In realtà, la crittografia non sarebbe necessaria per un token di sblocco - è possibile utilizzare la crittografia solo per scoraggiare gli intercettatori e si desidera contrastare gli intercettatori solo se il protocollo di verifica token è debole contro gli attacchi di riproduzione. In ogni caso, la crittografia è meglio lasciare a un livello in cui tutti i dettagli più difficili sono stati appianati in anni di fatica, e questo è SSL.