2013-07-30 11 views
5

Sto sviluppando un'applicazione Android utilizzando Mono per Android da Xamarin. Attualmente sto lavorando per aggiungere funzionalità di acquisto in-app utilizzando l'API di Google Play. Per fare ciò, ho bisogno di inviare a Google la chiave di licenza pubblica dalla mia app. Per quanto riguarda questo problema, Google raccomanda quanto segue: RaccomandazioneProtezione stringa in APK

Sicurezza: Si consiglia vivamente di non hard-code l'esatto valore della stringa chiave di licenza pubblica come previsto dalla Google Play. Invece, è possibile costruire l'intera chiave di licenza pubblica stringa in fase di esecuzione da sottostringhe o recuperarla da un archivio codificato , prima di passarla al costruttore. Questo approccio rende più difficile a le terze parti malintenzionate di modificare la stringa della chiave di licenza pubblica nel file APK.

Non mi sono mai occupato di crittografia, hacking/cracking o di qualsiasi altro aspetto della sicurezza del software, quindi non sono sicuro di come implementare il consiglio di Google. La mia domanda è: come fa uno adeguatamente proteggere una stringa in un APK Android realizzato con Mono per Android senza dover essere un esperto di sicurezza?

risposta

5

Non sembrare troppo audace, ma credo che si possa tranquillamente ignorare il loro suggerimento. I vantaggi di sicurezza di ciò che stanno suggerendo sono minimi al massimo.

Per una discussione più dettagliata leggere questo: How to protect Google Play public key when doing InApp Billing

La verità è che nessuno dei metodi descritti sono perfettamente sicuro. Se qualcuno è determinato a capire la tua chiave pubblica, lo faranno. Qualunque cosa tu faccia, la chiave pubblica finirà per essere passata al ctor, quindi un utente malintenzionato potrebbe sempre esaminarlo a questo punto. Tutti i "giochi" che stanno suggerendo rendono questo un po 'più difficile, ma sicuramente non impossibile.

Penso che la soluzione migliore sia accettarla per quello che è veramente. Questa chiave è pubblica per un motivo e devi convivere con il fatto che potrebbe essere facilmente compromessa. Dato che tutti gli altri dormono bene la notte sapendo questo, non vedo ragioni per cui non dovresti farlo :)

Se davvero non riesci a dormire la notte e vuoi fare qualcosa .. Inserisci la chiave nel tuo codice con i primi due personaggi sono passati. Quindi, durante il runtime, reinserisci i due caratteri prima di usare il tasto. Questo dovrebbe essere sufficiente per proteggersi dagli attacchi automatizzati di forza bruta. Attacchi intelligenti di cui non puoi fare nulla.

Edit:

Se siete alla ricerca di un modo standard di settore per proteggere il codice, utilizzare un obfuscator commerciale. Questi strumenti sono progettati per questo scopo. Alcuni esempi sono Mono for Android, code obfuscation. Assicurati di utilizzare versioni commerciali complete di funzionalità che includano la crittografia delle stringhe.

+0

Grazie per la risposta. Mi piacerebbe comunque conoscere un buon metodo standard di settore per risolvere questo problema, dal momento che il tasto Google Play non è l'unica stringa chiave della mia app (ad esempio anche la chiave dell'app Facebook e forse altre in futuro). – Ramsay

+0

Utilizzare uno strumento di offuscamento commerciale. Questi strumenti controllano il codice e rendono più difficile la decompilazione. Di solito quelli commerciali includono una funzione di crittografia automatica delle stringhe che assicura che tutte le stringhe codificate (come le chiavi) non siano mai mantenute in chiaro nella tua app e vengano decodificate in runtime. Sono disponibili molti offuscamenti per C#/android.Sono molto facili da integrare nel processo di compilazione e fanno tutto il lavoro più impegnativo per proteggere il tuo codice. – talkol

+0

Ecco un elenco di alcune delle tecniche utilizzate dagli offuscatori commerciali per infastidire i potenziali hacker: http://www.ssware.com/cryptoobfuscator/features.htm. Ricorda sempre che un determinato hacker sarà ancora in grado di superare tutto questo .. ma sarà molto meno divertente per lui;) – talkol