Android in-app di verifica di fatturazione

Question

Se Offload di verifica a un server remoto, penso che il processo sarà qualcosa del tipo:

Android Market     Application  Remote Server 
     |--------IN_APP_NOTIFY------->|    | 
     |        |-----nonce----->| 
     |        |<----nonce------| 
     |<-GET_PURCHASE_STATE_CHANGED-|    | 
     |---PURCHASE_STATE_CHANGED--->|    | 
     |        |--verification->| 
     |        |<-verification--| 

Se ho capito bene, il nonce è quello di ridurre la vulnerabilità attacco di riproduzione e la verifica è quello di ridurre la vulnerabilità spoofing. Inoltre, il motivo per cui i documenti consigliano di scaricare l'elaborazione della sicurezza è che la fase di verifica richiede l'accesso alla chiave pubblica del publisher Android Market e l'obiettivo del server remoto è quello di impedire che tale chiave venga inclusa/calcolata nel mio codice.

Prima domanda, esiste un motivo di sicurezza per il server remoto che esegue la generazione/controllo nonce? Premendo il passaggio di verifica è fatto correttamente, avremmo trovato dal server remoto se il messaggio è stato falsificato. Quindi mi sembra che il nonce sia lì solo per rilevare qualcuno che ritrasmette l'IN_APP_NOTIFY.

Seconda domanda, perché è importante se la nostra chiave pubblica è una stringa letterale? I documenti dicono, "non vuoi rendere più facile per un hacker o un utente malintenzionato sostituire la chiave pubblica con un'altra chiave". Non sono sicuro di come qualcuno possa sfruttare la mia app anche se fosse in grado di modificare il file binario per includere una chiave pubblica dannosa senza dover abbandonare l'app.

Terza domanda, non avrò tutti questi stessi problemi cercando di verificare la verifica dal mio server remoto (ad esempio, memorizzando la chiave pubblica sul mio server remoto nell'applicazione)?

Quarta domanda, è tutta questa sicurezza extra per nulla se voglio memorizzare i risultati di questa verifica di acquisto sul telefono (cioè non voglio dover verificare lo stato dell'acquisto del contenuto sbloccato ogni volta che un utente accede al contenuto)?

Answer 1

Prima domanda, esiste un motivo di sicurezza per il server remoto che esegue la generazione/controllo nonce?

Sì, il server deve generare il nonce e fare il controllo. Come regola generale, tutto ciò che riguarda la sicurezza dovrebbe quasi sempre essere fatto nel server. Un nonce è un "numero usato solo una volta". Quindi, la cosa corretta per il server è:

1. generare e salvare un nonce.
2. riceve una risposta.
   • se la risposta contiene un nonce salvato, controllare la firma ed elaborarla. CANCELLARE IL NONCE.
   • se la risposta contiene un nonce non salvato, è molto probabilmente uno fabbricato/replicato, quindi scarto.

Seconda domanda, perché è importante se la nostra chiave pubblica è una stringa letterale?

Un po 'se si eseguono controlli di sicurezza sull'applicazione, completamente irrilevante se si esegue il lavoro su un server (come si dovrebbe).

Se si esegue la sicurezza nell'applicazione, l'applicazione può essere compromessa per aggirare la sicurezza. Una tecnica è quella di cambiare la chiave pubblica, che è più facile se viene salvata come una singola stringa.

Terza domanda, non avrò tutti questi stessi problemi cercando di verificare la verifica dal mio server remoto (ad esempio, memorizzando la chiave pubblica sul mio server remoto nell'applicazione)?

No, non lo farai. Nessuno può accedere/modificare il codice del server. Almeno come "facile" come il barattolo nella domanda.

Quarta domanda, è tutta questa sicurezza extra per nulla se voglio memorizzare i risultati di questa verifica di acquisto al telefono (cioè non voglio dover verificare lo stato di acquisto del contenuto sbloccato ogni volta che un l'utente accede al contenuto)?

Bene, dipende.

Il modo "più sicuro" per implementare acquisti in-app con un server implica:

• si salva il contenuto "acquistabili" nel server. Se un utente lo acquista, lo scarichi nell'applicazione e tu lo salvi in ​​qualche modo per "copiare" su un altro telefono.
• dal server, invia solo contenuto se il processo di verifica viene eseguito correttamente NEL SERVER.
• dall'applicazione, se non si rileva alcun contenuto "salvato", eseguire un'operazione "ripristina transazioni" e quindi scaricare tutto ciò che è necessario dal server.
• Gli acquisti in-app di Google Play non sono progettati per fornire facilmente contenuti, sono progettati per eseguire acquisti da un sito centralizzato e, quindi, più semplici per l'utente. Noi sviluppatori finiamo con MOLTO lavoro per usarlo.