Tokens e processo di scambio chiavi tra device
I tokens sono principalmente delle chiavi di controllo che indicano ai device se concedere o meno l'uso delle API.
Grazie all'implementazione dei tokens è possibile mantenere un buon livello di privacy poiché implicano un complesso sistema di "amicizia" tra macchine, basato su scambio di chiavi RSA e cifratura blowfish.
Le chiavi pubbliche RSA a 2048 bit sono strutturate in questo modo:
-----BEGIN PUBLIC KEY-----
'Firma X509' + 'Firma PEM' + 'modulo' + 'ID' + 'esponente'
-----END PUBLIC KEY----- quindi le variabili sono:
-----BEGIN PUBLIC KEY-----
'MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A' + 'MIIBCgKCAQEA' + $modulus + 'ID' + $exponent
-----END PUBLIC KEY----- Da questa configurazione viene estrapolato il token, che altro non è che la somma md5 del $modulus della chiave.
$token = md5($modulus)Quando si fa una query ad un NAS, questi controlla la presenza del token fra i suoi trusted, e se presente abilita la risposta.
Naturalmente, questo meccanismo risponde unicamente a query effettuate attraverso le API ufficiali e mai attraverso il token del NAS stesso.
Per maggiori informazioni seguire la pagina relativa al parser delle API
Il meccanismo di acquisizione della fiducia tra NAS Ninuxoo si basa sullo scambio reciproco delle chiavi pubbliche RSA, generate in automatico al momento dell'installazione.
Possiamo paragonare il tutto a due persone che si conoscono e scambiano il numero di cellulare per la prima volta: il primo fa uno squillo al secondo, che poi si salva il numero.
Lo scambio avviene quindi in 3 fasi:
-
La macchina B comunica ad A di volersi connettere
Nell'esempio: B fornisce il proprio numero di telefono
Per fare questo l'operazione deve essere lanciata dal suo proprietario, così il NAS B trasmette la propria chiave pubblica RSA ad A e il fingerprint PGP del proprietario.
I dati vengono cifrati 2 volte con Blowfish: il primo livello contiene la data di inoltro, il secondo la chiave vera e propria e il fingerprint PGP del proprietario. -
A accetta e in cambio fornisce la propria chiave pubblica e un token per B
Nell'esempio: A fa uno squillo, dando implicitamente il proprio numero
A decifra il pacchetto ricevuto e aggiunge B fra i suoi trusted in forma di "knower" (conoscente) perché la sua identità deve essere ancora verificata.
Risponde così a B con la sua chiave pubblica RSA e il token, cifrando il tutto con la chiave pubblica di B appena fornita.
-
B risponde con la sua chiave pubblica e il token per A
Nell'esempio: B conferma che il numero di telefono è il suo
I dati vengono decifrati con la chiave privata di B.
B reinvia ad A la propria chiave pubblica appena fornita e decifrata da A.
B aggiunge A fra i suoi trusted e lo comunica via mail al proprietario.
A questo punto A riceve la chiave pubblica di B, decifrata per mezzo della propria chiave privata, e il timeout di 1 secondo impostato in precedenza viene interrotto perché è necessario l'intervento umano di A che deve dare conferma di conoscere "realmente" il proprietario di B: il NAS A invia quindi un'e-mail al suo proprietario che ha la possibilità di scegliere se accettare o meno. Nella mail viene fornito il fingerprint PGP del proprietario di B.
Una volta accettata la connessione dei NAS, A aggiunge B alle proprie cerchie, marcandolo come trusted in via definitiva (equivalente di: "D'accordo, salvo il numero").
In caso contrario, dovrà essere indicato se B deve essere ignorato o marcato come untrusted. In tal caso, le sue richieste di connessione future saranno solo riepilogate nel pannello di controllo di A (dove potrà comunque decidere se annullare il flag ricontrollando il fingerprint).
In questo modo sia A che B hanno a disposizione la reciproca chiave RSA pubblica e il relativo token generato dalla chiave, i rispettivi proprietari ne sono al corrente e hanno reciprocamente il proprio log salvato dalle loro macchine.
I device potranno così comunicare, ad esempio per una richiesta di ricerca locale.
Ogni azione intrapresa dai NAS, viene fin dal principio registrata in un log, il cui riepilogo via e-mail avverrà secondo la frequenza temporale impostata dall'utente (quotidiana, settimanale o mensile).
Ogni richiesta di API deve essere sempre fornita con il token del richiedente, che deve risiedere nel database trusted del ricevente; diversamente la richiesta viene rigettata perché naturalmente è necessaria l'autorizzazione personale.
- Sin dal principio e per tutte le altre operazioni, viene inoltrata la data della prima richiesta, perché ad ogni step successivo viene conteggiato il tempo trascorso: tutto il processo deve durare 1 minuto, termine dopo il quale sarà necessario ripetere l'operazione dal principio.
- Dopo 3 o più tentativi falliti, il proprietario del NAS viene avvisato via e-mail. Il numero di tentativi concessi potrà essere stabilito nel pannello di controllo.
- Già dal primo step, A effettua comunque un controllo dell'esistenza della chiave RSA, del token (estrapolato dalla chiave) e del fingerprint del proprietario sul proprio database. In tal caso il ciclo si conclude direttamente al passo 2 (e viene registrato nel log).
- È in fase di ragionamento una soluzione per poter avviare dei cicli di "sincronizzazione" automatizzata, dietro indicazione degli utenti attraverso crittografia PGP. Ogni referente di un NAS avrà così la propria cerchia di conoscenti coi quali condividere le directory di ricerca, per mezzo di questo script, che in altre parole, ingloba le condivisioni SAMBA remote tra le proprie, oppure, facendo semplicemente un merge dei risultati delle ricerche (che in caso punteranno ad un "collettore" ridondato).