Invio di dati crittografati tramite app Android

0

Ho un SDK per la mia app web, che l'utente può integrare nella sua app Android. Per l'autenticazione, abbiamo un authkey. E viene inviato come parametro POST o GET quando si verifica una comunicazione da server a server. Ma nell'app, temo che qualcuno possa ottenere l'authkey con qualsiasi metodo, durante la trasmissione. Per questo ho pensato di crittografare l'authkey, ma comunque, sarà sempre la stessa authkey crittografata e qualcuno potrà ottenere solo authkey ecnrypted e può usare lo stesso per inviare dati.

Per evitare questo, sono venuto con una logica, che penso sia abbastanza sicura per inviare authkey con crittografia e inviando ogni volta una chiave di autenticazione crittografata diversa. Ecco il processo.

  1. Ho un authkey, diciamo ABCD1234, che ho bisogno di inviare
  2. Genero un numero casuale crittograficamente sicuro, lo chiamo rand_number
  3. Poi crittaggio la mia authkey con questo numero_and, usando 'aes-256-cbc', e lo chiamo come auth_token
  4. Quindi crittaggio il numero_rand con la mia chiave pubblica e lo chiamo come time_token.
  5. Trasmetto quindi auth_token e time_token al mio server

E lato server:

  1. Decreterò time_token con la mia chiave privata e otterrò rand_number
  2. Decrittografa auth_token con questo rand_number e ottiene authkey.

Questo metodo è abbastanza sicuro? Anche se riveliamo l'intero processo di crittografia e invio dei dati?

Non lo so, ma ho la sensazione che, questo sarebbe un metodo già esistente.

    
posta kadamb 24.05.2017 - 11:18
fonte

2 risposte

1

Ci sono una serie di problemi con il tuo schema. Iniziamo con il più semplice, però:

Quello che stai cercando di fare non può essere fatto.

A quanto ho capito, stai cercando di nascondere un token simmetrico (authkey), che è presente in ogni copia della tua app, così che qualcuno non possa scrivere un altro client per la tua app web. Questo è impossibile.

  1. La tua app deve contenere il token. Chiunque possa ottenere l'app - che, se si trova nel Play Store, è qualcuno - può decodificare l'app per ottenere il token. La crittografia del token non aiuta; l'autore dell'attacco ha solo bisogno di conoscere il token nello stesso modulo che l'app lo conosce.
  2. La tua app deve utilizzare il token. Quell'uso è implementato nel codice. Indipendentemente dal modo in cui lo si implementa, lo stesso codice sarà disponibile per un utente malintenzionato per copiare semplicemente nella propria app (anche se si tratta di un blob binario, se necessario).

Ok, su specifici difetti nel tuo schema.

Riproduci attacchi

Il tuo schema non ha alcun nonce, e quindi l'attaccante può semplicemente inviare la stessa coppia auth_token + time_token che è stata catturata dal traffico dell'app. Time_token continuerà a decodificare sullo stesso numero_rand utilizzato per crittografare authkey. Questo è il modo più banale per rompere lo schema; l'attaccante non ha nemmeno bisogno di sapere cosa significano i token.

Dimensione chiave

Non menzioni la lunghezza della authkey, o come è stata generata. Dato che hai esplicitamente menzionato questo per il numero_rand, ma invece hai dato un token di esempio molto breve per authkey, temo che potrebbe essere troppo facile da usare come forza bruta. L'utente malintenzionato non ha bisogno di sapere quale sia la chiave di decodifica se l'intero intervallo di valori da cercare è sufficientemente piccolo.

Prestazioni

Lo schema richiede due operazioni crittografiche asimmetriche per messaggio, una lato client e una lato server. La crittografia asimmetrica è computazionalmente piuttosto costosa. Gli schemi che lo utilizzano quasi sempre eseguono semplicemente un singolo scambio di chiavi che lo utilizza e quindi riutilizzano la chiave scambiata per tutte le comunicazioni effettive o sono per operazioni asincrone (come la posta elettronica o la verifica dell'integrità del download) in cui le prestazioni non sono importanti.

Re-implementazione della ruota

Se sei preoccupato solo per la sicurezza di comunicazione (che di solito non è sufficiente quando c'è un token statico coinvolto, ma è l'unico vettore di minacce che hai esplicitamente menzionato ...) allora dovresti sta usando TLS (HTTPS, poiché il formato del messaggio è HTTP). Se vuoi essere più sicuro, aggiungi il certificato del server (o almeno le informazioni sulla chiave pubblica dell'oggetto dal certificato) nella tua app, in modo che un utente malintenzionato non possa fare cose come installare un nuovo certificato radice attendibile e utilizzare la sua chiave privata spoofare il certificato del tuo server.

    
risposta data 23.07.2017 - 22:54
fonte
0

Dovresti utilizzare un MAC per firmare tutti i dati dell'API trasmessi con la "chiave di autorizzazione" come segreto MAC.

Non dovresti mai implementare il tuo protocollo crittografico se non è assolutamente necessario.

    
risposta data 24.05.2017 - 11:50
fonte

Leggi altre domande sui tag