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.
- 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.
- 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.