Non è chiaro cosa stai cercando di proteggere contro, ma in ogni caso stai facendo qualcosa di sbagliato.
Stai tentando di impedire a un utente malintenzionato di MitM di intercettare il traffico di utenti legittimi? Basta usare TLS (HTTPS). Seriamente, è il risposta corretta per questo scenario. Finché utilizzi cifrari e librerie moderne (su entrambe le estremità), sarai al sicuro da quasi tutti gli attaccanti immaginabili (molto meno probabile). Se si desidera essere particolarmente attenti, collegare il certificato o le informazioni sulla chiave pubblica del server (o della CA, a un livello superiore della catena) in modo che anche una CA compromessa o dannosa non consenta a qualcuno di violare il canale di comunicazione.
Stai cercando di usare questo come una sorta di meccanismo di autenticazione? Utilizzando crypto per stabilire che entrambi i fini della comunicazione conoscono una chiave condivisa, e quindi stabilire l'identità del client, è una valida idea per un'API RESTful (AWS, ad esempio, fa questo con il loro schema SigV4 ). Tuttavia, per fare ciò, è necessario utilizzare una forma autenticata di crittografia. Cipher Block Chaining (CBC) non fornisce alcuna autenticazione; un utente malintenzionato che conosce parte del testo in chiaro per un messaggio protetto solo da AES (o qualsiasi altro codice a blocchi) in modalità CBC può manipolare il testo cifrato per produrre un cambiamento affidabile nel testo normale e né la vittima né il server saprà. Si può notare che SigV4 in realtà non esegue alcuna crittografia (solo HMACs, una forma di firma crittografica a chiave simmetrica); non fornisce alcuna riservatezza (HTTPS lo fa), solo autenticità (assicurando che il messaggio provenga dalla fonte reale e che non sia stato manomesso in volo). È possibile risolvere questo problema utilizzando una modalità di crittografia autenticata (come GCM), o usando firme asimmetriche (ma allora si può anche usare il mutuo TLS!), O adottando uno schema come SigV4 (o semplicemente adottandolo direttamente .. .), ma il tuo schema attuale non funzionerebbe.
Stai cercando di impedire alle persone di capire come scrivere client di terze parti per la tua API? Non puoi impedirlo. Non disturbarti a provare. Indipendentemente dall'analisi del traffico di rete, dalla retroingegnerizzazione dei binari o da qualche altra strada, non è possibile impedire alle persone di trovare una chiave che hanno per fornire ai propri utenti. I migliori (in termini di conoscenze tecniche e risorse ingegneristiche applicate) sono i sistemi commerciali DRM che "proteggono" cose come film e software commerciale, e quelli sono ancora rotti (a volte con facilità esilarante). È fondamentalmente impossibile impedire che si rompano, anzi; il meglio che puoi sperare è nascondere la chiave e l'oscurità è non sicurezza.