Controllo della sicurezza mentale

Sì, se lo descrivi con precisione questo è completamente rotto, fino al punto di inutile.

La chiave AES iniziale è compromessa dall'app, chiunque abbia l'app ha accesso alla chiave AES. Se questo è globale, allora è ben fatto, se è unico per ogni applicazione, potrebbe esserci un piccolo frammento di speranza.

SHA-1 è completamente rigiocabile. Non si parla di sale, ma anche se c'è un sale, l'attaccante può riprodurlo contro un client legittimo come un MitM e quindi rispondere validamente per apparire come client sul server.

Il server fornirebbe quindi l'hacker con la chiave pubblica, in forma crittografata, che non è particolarmente utile per l'aggressore, ma è anche la chiave pubblica ... dovrebbe essere pubblica. Avendolo privato non offre nulla. Se il client è stato mai compromesso (o qualsiasi client se la chiave AES è globale), il tasto AES viene divulgato dall'applicazione e la chiave pubblica è disponibile anche per l'autore dell'attacco.

Inoltre, se la chiave AES è compromessa, l'utente malintenzionato può inviare una chiave pubblica a sua scelta poiché il client non ha modo di verificare la chiave pubblica RSA.

Una chiave AES generata sul client è un'idea abbastanza decente, ma finora non c'è nulla che impedisca all'aggressore di generare la propria chiave AES. Inoltre, potrebbero probabilmente fornire al cliente la propria chiave pubblica in modo da poter ingannare anche il client.

Perché i dati vengono crittografati con la chiave RSA? Qual è il punto della chiave AES temporanea allora? È davvero completamente inutilizzato? La crittografia dei dati lunghi con RSA è generalmente considerata meno sicura rispetto all'utilizzo della crittografia simmetrica poiché richiede più lavoro da elaborare e può avere altre implicazioni sulla sicurezza, la norma è solo per scambiare una chiave simmetrica e utilizzarla per lo scambio di dati.

In breve, il sistema è completamente inutile.

Sarebbe molto più utile se incorporasse semplicemente la chiave pubblica del server nell'applicazione e la usasse per fare in modo che il client generi una chiave AES e la scambiasse per le comunicazioni di sessione. Non verrebbe convalidato nulla sul client stesso, ma ciò potrebbe essere fatto tramite password o altri token dopo l'inizializzazione della sessione. A quel punto sei abbastanza vicino a usare solo un HTTPS autofirmato, ma potrebbe essere usato come implementazione personalizzata se HTTPS non è un'opzione per qualche motivo (come non essere in grado di aggiungere un certificato di root attendibile sul client dispositivi).

Bene, la chiave AES incorporata nella libreria è completamente inutile e sembra che non ci sia alcuna convalida del lato server. Vedo molti problemi con questo schema.

1. Chiunque abbia accesso alla libreria Android può estrarre il codice AES.
2. L'invio di un hash di un valore statico su un semplice HTTP equivale a inviare una password su un semplice HTTP. Chiunque può catturarlo dall'osservazione passiva, quindi non c'è autenticazione del client.
3. Non c'è autenticazione del server, quindi se ottengo l'accesso a un client (e quindi posso rubare la chiave AES statica) posso MITM qualsiasi client, inviare la mia chiave RSA e leggere / modificare / manomettere tutto il traffico .

Non parli di come viene implementato AES (quale modalità, come viene generato IV, ecc.) in quale modalità / padding viene usata la chiave RSA (se usata non imbottita, o "RSA da manuale", è ancora di più rotto).

Hai detto che questo è utilizzato per l'elaborazione della carta di credito e, anche se non sono un esperto PCI, sono abbastanza sicuro che ciò non supererebbe la conformità PCI.