[Google Cloud services] Come funziona il meccanismo di autenticazione ?

[das]

Stop sviluppando una app che si basa sui servizi di Google Cloud.

Siccome questi servizi sono a pagamento, per funzionare hanno bisogno di un APIKey che si appoggia su carta di credito.

Al momento di creare un'APIKey sul sito di google, è chiesto il nome del package e l'hash SHA1 del certificato con il quale viene firmata l'app. Sulla base di questi dati viene generato un codice di lettere e numeri che corrisponde all'APIKey.

Ora la domanda è questa:
come fa google a stabilire che l'uso dell'APIKEy è legittimo ?


Su internet non ho trovato nessun dettaglio a riguardo, ma dovrei sapere come funziona per essere sicuro che qualcuno non decompili il programma, si freghi l'Apikey e poi la usi nella sua app addebitando i costi a me.


Grazie.

[tomminno]

Dipende tutto dall'app. Probabilmente dovresti usare una tua API con una tua autenticazione e accedere a google cloud lato server senza mai esporre l'apikey direttamente nell'app.
Se sei proprio obbligato ad usare la chiave nell'app, una strada potrebbe essere quella di usare Proguard (o un qualunque altro offuscatore) e di trasformare la tua apikey in un calcolo, in questo modo non è presente sotto forma di stringa e quindi ricercabile o estrapolabile in qualche modo (es tramite strings) e il codice relativo al calcolo è "protetto" da Proguard.
Qualunque altra soluzione che preveda la presenza della stringa nell'app è aggirabile facilmente.
Si vedono in giro tanti articoli che indicano di tenere la chiave in una libreria nativa (NDK), evidentemente non sanno che le stringhe costanti sono estraibili semplicemente anche da una libreria .so. Infine allegare all'app una libreria magari dal nome keyvault.so non è molto furbo

Ovviamente niente ti mette al riparo dal fatto che chi utilizza l'app sappia che dentro in qualche formato esiste la tua apikey, si tratta solo di rendere il percorso per ottenerla più difficile.

[das]

Originariamente inviato da tomminno

Dipende tutto dall'app. Probabilmente dovresti usare una tua API con una tua autenticazione e accedere a google cloud lato server senza mai esporre l'apikey direttamente nell'app.
Se sei proprio obbligato ad usare la chiave nell'app, una strada potrebbe essere quella di usare Proguard (o un qualunque altro offuscatore) e di trasformare la tua apikey in un calcolo, in questo modo non è presente sotto forma di stringa e quindi ricercabile o estrapolabile in qualche modo (es tramite strings) e il codice relativo al calcolo è "protetto" da Proguard.
Qualunque altra soluzione che preveda la presenza della stringa nell'app è aggirabile facilmente.
Si vedono in giro tanti articoli che indicano di tenere la chiave in una libreria nativa (NDK), evidentemente non sanno che le stringhe costanti sono estraibili semplicemente anche da una libreria .so. Infine allegare all'app una libreria magari dal nome keyvault.so non è molto furbo

Ovviamente niente ti mette al riparo dal fatto che chi utilizza l'app sappia che dentro in qualche formato esiste la tua apikey, si tratta solo di rendere il percorso per ottenerla più difficile.

Ma come mai Google chiede di leggere l'Apikey all'hash sha1? In che modo viene usata la stringa sha1?
Io pensavo che in qualche modo servisse a proteggere l'Apikey

[71106]

Originariamente inviato da das

Ma come mai Google chiede di leggere l'Apikey all'hash sha1? In che modo viene usata la stringa sha1?
Io pensavo che in qualche modo servisse a proteggere l'Apikey

Premesso che non lo so: un hash è una funzione facile da calcolare ma "difficile" da invertire, dove "difficile" significa "ragionevolmente impossibile".

Quindi dato X puoi calcolare Y, ma dato Y non puoi calcolare X. Nel tuo caso X è l'API key, Y è l'hash.

Ciò detto suppongo che questa API key venga trattata come una password: solo tu la conosci, Google non la conosce, ma Google ne conosce l'hash cosicchè per verificarla Google ne ricalcola l'hash e vede se corrisponde a quello conosciuto per la tua API key.

[das]

Originariamente inviato da 71106

Premesso che non lo so: un hash è una funzione facile da calcolare ma "difficile" da invertire, dove "difficile" significa "ragionevolmente impossibile".

Quindi dato X puoi calcolare Y, ma dato Y non puoi calcolare X. Nel tuo caso X è l'API key, Y è l'hash.

Ciò detto suppongo che questa API key venga trattata come una password: solo tu la conosci, Google non la conosce, ma Google ne conosce l'hash cosicchè per verificarla Google ne ricalcola l'hash e vede se corrisponde a quello conosciuto per la tua API key.

Google al momento di darmi l'Apikey mi chiede l'hash della chiave (casuale) con la quale firmo l'app. Dunque google conosce sia l'apikey che l'hash. L'unica spiegazione che mi do è che al momento di inviare la query a google Android in qualche modo invii la firma
dell'app in esecuzione e Google verifichi che è compatibile con il relativo hash SHA1 che lui ha già.
Però non sono sicuro che sia così e poi in questo modo craccandob il sistema operativo si potrebbe ingannare google e usare illegittimamente l'apikey

[das]

*

[71106]

Originariamente inviato da das

Google al momento di darmi l'Apikey mi chiede l'hash della chiave (casuale) con la quale firmo l'app. Dunque google conosce sia l'apikey che l'hash. L'unica spiegazione che mi do è che al momento di inviare la query a google Android in qualche modo invii la firma
dell'app in esecuzione e Google verifichi che è compatibile con il relativo hash SHA1 che lui ha già.
Però non sono sicuro che sia così e poi in questo modo craccandob il sistema operativo si potrebbe ingannare google e usare illegittimamente l'apikey

Ah ok, scusa.

Comunque il modo di usare gli hash solitamente è quello, ossia verificare una password o elemento analogo senza che il server la conosca e senza che il client debba mandargliela in chiaro. Quindi deduco che la chiave che menzioni (quella con cui hai firmato l'applicazione) sia ritenuta segreta. Contro-deduco che, se così non fosse, essa sarebbe soggetta a spoofing nel senso che chiunque potrebbe dire a Google "sisi, questa è l'app di das, vedi? questa è la chiave con cui l'ho firmata, corrisponde a quella usata da das!". Ergo, deduzione finale, ritengo che Google sia soddisfatto solo quando gli mandi la giusta accoppiata di API key e hash della chiave.

Se il procedimento di calcolo dell'hash non include un valore di salt o di challenge, e quindi l'hash è sempre lo stesso, la tua app non deve contenere la chiave in chiaro ma solo l'hash.

Ha senso? Ho tirato tutto a indovinare.

[71106]

D'altro canto al mio ragionamento manca un passaggio: se il calcolo dell'hash non include salt o challenge, un attaccante può limitarsi a spoofare l'hash e non gli serve sapere la chiave.

Però comprendo il tuo dubbio circa il memorizzare la chiave nell'applicazione in qualche forma, che anche nel caso più sofisticato diverrebbe una semplice "security by obscurity" e quindi nessuna garanzia.

Boh.

[das]

Originariamente inviato da 71106

D'altro canto al mio ragionamento manca un passaggio: se il calcolo dell'hash non include salt o challenge, un attaccante può limitarsi a spoofare l'hash e non gli serve sapere la chiave.

Però comprendo il tuo dubbio circa il memorizzare la chiave nell'applicazione in qualche forma, che anche nel caso più sofisticato diverrebbe una semplice "security by obscurity" e quindi nessuna garanzia.

Boh.

Sì, infatti quello che non mi torna è:
-chi installa l'applicazione regolarmente ha tutte le informazioni e le istruzioni per usare la chiave

-cosa impedisce a chi ne vuole fare un uso fraudolento di utilizzare quelle informazioni/istruzioni per fingrere di essere l'app originale. Al momento mi pare che nulla glielo impedisca.

-L'unica cosa che posso pensare è che comunque per frodare sia necessario anche craccare il sistema operativo e quindi di fatto l'app fraudolenta non possa essere diffusa su PlayStore come fosse una qualsiasi app regolare.

[71106]

Cominciamo a chiarire il punto cruciale di cui sopra, come viene calcolato l'hash SHA1 di preciso? Ci sono valori di challenge inviati dal server, valori di salt casuali, o è solo l'hash nudo e crudo?

Originariamente inviato da das

L'unica cosa che posso pensare è che comunque per frodare sia necessario anche craccare il sistema operativo

Perchè?

[das]

Originariamente inviato da 71106

Cominciamo a chiarire il punto cruciale di cui sopra, come viene calcolato l'hash SHA1 di preciso? Ci sono valori di challenge inviati dal server, valori di salt casuali, o è solo l'hash nudo e crudo?

Ogni applicazione viene firmata con un certificato, cioè lettere e numeri casuali creati una sola volta e sempre uguali.
Da questo certificato si ricava anche un hash sha1 che va inserito nell'apposito form di google quando si crea una nuova apikey. Il codice sha1 va anche inserito nel manifest dell'applicazione in chiaro. Quindi sia l'SHA1 che l'APIKEy sono due informazioni che ha lo sviluppatore, ha google, hanno gli utenti.

Perchè?

Perchè potrebbe essere (ma non so) che Android invii a google anche la firma dell'App al momento di utilizzare le API che consentono di fare le query.

E che quindi Google possa verificare che la firma dell'app sia coerente con l'Hash sha1 legato all'APIKey che si sta usando.

Quindi per ingannare Google cloud sarebbe necessario craccare Android per obbligarlo ad inviare la firma giusta anche se l'app è sbagliata.

Ma sono solo ipotesi.

[71106]

Originariamente inviato da das

Ogni applicazione viene firmata con un certificato, cioè lettere e numeri casuali creati una sola volta e sempre uguali.
Da questo certificato si ricava anche un hash sha1 che va inserito nell'apposito form di google quando si crea una nuova apikey. Il codice sha1 va anche inserito nel manifest dell'applicazione in chiaro. Quindi sia l'SHA1 che l'APIKEy sono due informazioni che ha lo sviluppatore, ha google, hanno gli utenti.

Se questo è il quadro completo mi pare di capire che Google esegua un processo di validazione su un set di informazioni costanti, cioè sempre uguali, e quindi si, soggette a spoofing. Che queste informazioni si chiamino "hash", "APIKey", "certificato", ecc. è irrilevante: se sono sempre uguali chiunque può spacciarsi per la tua app.

Qua le cose sono due: o ti manca qualche dettaglio che rende sicuro questo schema, o tu puoi sviluppare un PoC ("proof of concept") che dimostra a Google una falla di sicurezza che permette a qualunque sviluppatore di usufruire dei servizi a spese di altri. Propendo di più per la prima.

L'ipotesi che riporti, ossia che del software presente sul telefono e considerato sicuro verifichi la firma dell'app prima di inviarne l'hash ai backend di Google, è un'ipotesi valida ma ritengo che non costituisca una misura di sicurezza sufficiente perchè un'app maliziosa può molto probabilmente trovare il modo di effettuare una connessione diretta ai backend di Google ignorando totalmente il software sicuro di cui sopra.

Di preciso come fa la tua app ad usufruire di questi servizi a pagamento? Che API usi?

[das]

Originariamente inviato da 71106

Se questo è il quadro completo mi pare di capire che Google esegua un processo di validazione su un set di informazioni costanti, cioè sempre uguali, e quindi si, soggette a spoofing. Che queste informazioni si chiamino "hash", "APIKey", "certificato", ecc. è irrilevante: se sono sempre uguali chiunque può spacciarsi per la tua app.

Qua le cose sono due: o ti manca qualche dettaglio che rende sicuro questo schema, o tu puoi sviluppare un PoC ("proof of concept") che dimostra a Google una falla di sicurezza che permette a qualunque sviluppatore di usufruire dei servizi a spese di altri. Propendo di più per la prima.

L'ipotesi che riporti, ossia che del software presente sul telefono e considerato sicuro verifichi la firma dell'app prima di inviarne l'hash ai backend di Google, è un'ipotesi valida ma ritengo che non costituisca una misura di sicurezza sufficiente perchè un'app maliziosa può molto probabilmente trovare il modo di effettuare una connessione diretta ai backend di Google ignorando totalmente il software sicuro di cui sopra.

Di preciso come fa la tua app ad usufruire di questi servizi a pagamento? Che API usi?

Al momento sto usando il sistema ufficialmente 'non sicuro' ma che va bene per le prove:
PostString("https://vision.googleapis.com/v1/images:annotate?key="+ApiKey,outString)

PostString è il metodo POST dell http che invia il JSON con i dati da elaborare all'indirizzo https://vision.googleapis.com/v1/images:annotate?key="+ApiKey dove APIKey è la chiave.

Dovrei implementare il metodo sicuro, dove quà ci sono gli esempi in python o java:
https://cloud.google.com/vision/docs/landmark-tutorial

Ad ogni modo ho trovato questa pagina da cui sembrerebbe che google sappia che il suo sistema non è sicuro: https://support.google.com/cloud/answer/6310037

E secondo me non è sicuro perchè se ci pensi, come potrebbe funzionare un metodo sicuro ?
Anche se ci fosse una componente che varia (per esempio l'orologio) e che fa variare sempre i dati in uscita uno potrebbe sempre fare il dump della ram e vedere in chiaro la chiave prima che venga cifrata.

Non so che dire; da un lato mi sembra assurdo che un sistema che attinge direttamente dalla carta di credito sia così vulnerabile, dall'altro non ho idea di come potrebbe essere fatto. Forse è questo il motivo per cui vogliono la carta di credito vera e non ricaricabile, perchè con quella vera il pagamento va sempre a buon fine e poi sono cavoli tuoi.