The AES key is hard coded in the code.
Questo è il problema. Ma no, la crittografia della chiave con un'altra chiave (che sarebbe codificata nel codice) non migliora sostanzialmente le cose.
Quello che devi fare è il seguente: annota il modello di attacco . Stai facendo la crittografia per una ragione: credi che un individuo malvagio proverà a fare ... che cosa esattamente? Questo è il punto del modello di attacco: per definire cosa può fare il presunto aggressore e cosa vorrà ottenere. Solo con un modello di attacco chiaramente definito puoi iniziare a pensare a quali algoritmi e protocolli di sicurezza ti aiuteranno.
Ad esempio, la crittografia è uno strumento utile per riservatezza : in quel momento l'autore dell'attacco desidera leggere alcuni dati, ma non vuoi che abbia successo. La crittografia non risolve la riservatezza ; si concentra solo il problema: con la crittografia, il problema di mantenere riservati i dati diventa il problema di mantenere il tasto confidenziale. Poiché la chiave è più breve, questo può (o non può) rendere il problema più facile da gestire. Un punto importante è decidere chi dovrebbe essere in grado di accedere ai dati.
Per farla breve: se si suppone che i dati siano decifrati sulla macchina dell'attaccante (ad esempio, l'utente malintenzionato è l'utente e si desidera impedirgli di accedere ai dati non elaborati come parte di una sorta di licenza o schema DRM), quindi, per dirla senza mezzi termini, si perde. Non è possibile impedire in modo affidabile e coerente a qualcuno di accedere ai dati che fluiscono sul proprio hardware. Questo perché reverse engineering funziona bene. Se si sovrappongono i livelli di crittografia (la chiave è crittografata con un'altra chiave crittografata con un'altra chiave, e così via, fino a una chiave iniziale che è codificata in modo rigido), si aumenta solo il tempo di sviluppo e il tempo di reverse engineering; è probabile che ti costerà più tempo per te che per l'aggressore.