Quali algoritmi possono essere utilizzati per l'accoppiamento del dispositivo?

4

Devo implementare un sistema in cui i dispositivi Android si collegano a un server centrale e devono registrarsi con account utente diversi, quindi ho deciso di creare un accoppiamento dance simile a quello che può essere osservato in bluetooth abbinamento, o software come l'accoppiamento remoto apple con la libreria itunes. Sto cercando informazioni su quali algoritmi di crittografia possono essere utilizzati durante questa comunicazione utilizzando un canale di comunicazione separato per la chiave di crittografia. L'algoritmo che ho pensato avrebbe seguito questi passaggi:

  1. Il dispositivo si accende e chiama un server fisso per annuncia stesso.
  2. Il dispositivo mostra alcuni numeri casuali sullo schermo (ad esempio 392582).
  3. L'utente deve accedere al server con un browser Web nel suo account e digitare la sequenza numerica vista sul dispositivo (potrebbe essere eseguita sul dispositivo Android stesso).

Durante il passaggio 1 il client comunicava al server tramite SSL. Il numero mostrato all'utente nel passaggio 2 sarebbe parte di una stringa predeterminata statica più lunga che verrebbe sottoposta a hash. Il server e il client scambiano l'hash e verificano che sia lo stesso. Se lo è, significa che l'associazione è OK. Alcune domande mi perseguitano:

  1. In realtà questo suono o i dispositivi di parsing sono fatti in altri modi?
  2. Sto usando MD5 hashing abbastanza per questo o dovrei usare altri hash?
  3. Quale durata e scadenza devono avere il codice dello schermo per evitare collisioni con altri potenziali utenti?
  4. Quali perfezionamenti possono essere fatti per migliorare l'autenticità della connessione? Ho però intenzione di sostituire la stringa statica più lunga predefinita con l'hash con una stringa casuale. Il client invierà il seme del generatore di numeri casuali durante il primo passaggio. Un uomo nel mezzo avrebbe ancora capito, ma questo ridurrebbe le collisioni di hash con altri utenti?
  5. Mi manca il gergo tecnico di sicurezza, forse questo è un processo ben studiato e ci sono tonnellate di articoli su wikipedia su di esso? Le informazioni su wikipedia sull'associazione / associazione bluetooth non forniscono troppi dettagli tecnici sull'implementazione. Dove dovrei cercare?
posta Grzegorz Adam Hankiewicz 03.04.2012 - 10:46
fonte

2 risposte

2

Rilegato penso di vedere cosa stai cercando di realizzare. L'utente ha un account su www.example_business.com e ora vuole utilizzare la nuova app android di business di esempio. Hai deciso di non volere che l'utente debba effettuare il login completo tramite la tua app Android. Forse hai bisogno dell'autenticazione a due fattori (in cui il secondo fattore è il telefono), o richiedi certificati, o temi i keylogger di tipo carrier-IQ e non vuoi eseguire la procedura di accesso completa al telefono.

  1. Il client apre mobile_app per la prima volta, che chiede all'utente il loro user_name , e quindi invia una richiesta al server per il token con user_name . (Se user_name non esiste, non comunicare con l'app mobile).
  2. Il server genera random_number (ad esempio dieci cifre base36 con le opzioni 36 ^ 10 ~ 10 ^ 15 visualizzate inizialmente in minuscolo per distinguere 0 da O) e inviarlo al sito web. Il server invia timestamp + sha256hash (timestamp + user_name + random_number + high_entropy_secret_key_only_known_by_server) all'app mobile e le istruzioni per accedere al sito Web per ottenere il numero casuale. La chiave segreta high_entropy dovrebbe essere qualcosa del tipo: TQy9p4pDDHpZuS3Fimdag6yCtU9YBCt55PntmPyUPD_oxRMW3f che viene tenuta segreta sul server.
  3. Il client si collega al sito Web, legge random_number e digita random_number in mobile-app.
  4. L'app per dispositivi mobili invia data / ora (dal punto 2), nome_utente, hash ricevuto (dal punto 2) e numero_campo (dal punto 3) al server.
  5. Il server verifica che il timestamp non sia troppo vecchio (diciamo meno di un giorno), non è stato inserito nella blacklist da troppi tentativi errati, controlla che l'hash corrisponda all'hash dei dati ricevuti (non fa distinzione tra maiuscole e minuscole; abbassa il caso di random_number ), quindi invia un token all'app mobile che collega i due account.

Per quanto riguarda la lista nera dopo troppi tentativi falliti; Inserirò nella lista nera nomi utente + timestamp che hanno fallito tre volte; puoi svuotare la lista nera ogni giorno (dal momento che funzionano solo i timestamp di un giorno); avere un processo di riavvio dell'app per dispositivi mobili con nuovo timestamp / random_number).

Utilizzerei SSL per tutte le trasmissioni per prevenire gli intercettatori. Ora per un utente che non ha un account ma conosce un user_name valido e sta provando a forzare il numero casuale, avranno una possibilità di indovinare 1 su 10 ^ 15 (circa 20 milioni di volte meno probabile che vincerà la lotteria) correttamente per tentativo. Ma istituirei ulteriormente un passo in cui limiti gli accessi per gli indirizzi IP e gli account che non riescono a sincronizzare i tentativi troppe volte.

    
risposta data 03.04.2012 - 18:59
fonte
0

EEtimes ha elenchi di fornitori per i vari chipset di interesse. Onestamente, il modo in cui hai posto la domanda mi dice che stai superando un progetto qui. Trenta minuti sul sito ti faranno risparmiare un sacco di problemi in seguito, se ti prendi il tempo di leggere alcuni white paper approfonditi ed evitare di reinventare la ruota.
Il poster precedente ti ha fatto un enorme favore e sono profondamente impressionato dal suo livello di dettaglio per conto del tuo progetto.  Spero che sia d'aiuto,       iceberg

    
risposta data 06.04.2012 - 08:52
fonte

Leggi altre domande sui tag