API - Problemi di progettazione della sicurezza

Sembra che tu voglia fornire un'app che pagherà i tuoi abbonati per inviare messaggi SMS per tuo conto. Ma poiché l'invio di messaggi potrebbe costare ai clienti, pensi che i tuoi clienti potrebbero tradirti affermando di aver inviato il messaggio senza averlo effettivamente inviato.

A meno che non esista un componente crittografato affidabile all'interno dei modem GSM in grado di fornire un rapporto firmato sullo stato, probabilmente non c'è modo di applicarlo tramite mezzi crittografici. I clienti sono sempre in grado di fornire le proprie implementazioni.

Quindi, preferirei affrontarlo con una metodologia di test casuale. Per ogni cliente, il tuo server potrebbe decidere in modo casuale quando inviarli a un destinatario fidato. Forse il messaggio di test viene inviato una volta su dieci messaggi ordinari o un messaggio su 50, qualcosa del genere. Forse costruisci i test su una scala mobile. Per iniziare, uno dei primi tre o quattro è un messaggio di test, quindi mentre continuano a superare i test, si riducono i requisiti di test. Se qualcuno sta barando, non riceverai l'SMS e potrai investigare.

Devi essere premuroso nel design, ovviamente. È possibile scriverlo nell'accordo EULA informando i clienti che il sistema invierà periodicamente messaggi di test e che potranno essere annullati a propria discrezione. Ma non devi dare loro dettagli sulla metodologia di test. Se i tuoi clienti possono sapere esattamente quali messaggi sono i messaggi di prova, potrebbero ancora imbrogliare e rispondere solo ai test. Quindi i messaggi di test devono assomigliare a messaggi ordinari e devono andare a destinazioni dall'aspetto normale. E se un messaggio non riesce ad arrivare, non dovresti immediatamente decidere di averti tradito, poiché ci sono molti altri componenti che potrebbero essersi infranti. Dovresti investigare.

Un'opzione diversa potrebbe essere quella di richiedere che i clienti forniscano la prova dell'invio sotto forma di copia della loro dichiarazione di fatturazione. I sistemi GSM registrano tutte le destinazioni dei messaggi SMS. Forse potresti organizzare con i fornitori GSM la verifica dei loro record? Correlati, forse potresti affittarli i modem GSM e fornirti i conti da solo, con i clienti che ti pagano per il servizio GSM.

Non puoi fidarti di dispositivi non fidati. Questa asserzione tautologica significa che il software che gira su hardware controllato da un attaccante può essere ispezionato e modificato dall'attaccante a piacimento; non c'è alcun segreto che possa essere nascosto in tale codice, che l'attaccante non sarà in grado di imparare. Non c'è modo di garantire che il codice che chiama un determinato server sia realmente il "tuo" codice e non una versione modificata.

Un proof-of-work non aiuta. Le prove di lavoro hanno lo scopo di risolvere un altro problema, ovvero l'invio di richieste di massa: in questa configurazione, riconosciamo che il chiamante potrebbe essere stato arbitrariamente alterato dall'attaccante; ma il proof-of-work consente al server di garantire che, almeno , il codice dell'attaccante ha dovuto investire notevoli quantità di potenza di calcolo per ogni richiesta.

Nel tuo caso, il tuo problema non è una questione di invio di massa di richieste, quindi le prove di lavoro non si applicano. Il tuo problema è che un componente non affidabile dovrebbe inviare un SMS (con contenuti definiti) e poi dirti che lo ha fatto, e potrebbe mentire. Vedo alcuni possibili soluzioni alternative, nessuna veramente soddisfacente:

• È possibile utilizzare per il client non fidato alcuni hardware dedicati e resistenti alle manomissioni. Questo è ciò che accade con alcuni terminali di pagamento : il terminale è protetto e si suicida quando il suo caso è aperto; quindi qualunque codice venga eseguito in esso può ora essere considerato "affidabile".

• Sostituisci l'SMS con MMS . Non sono sicuro dei dettagli, ma a quanto pare è possibile taggare un MMS da inviare a più destinatari, in modo che il codice possa inviare l'MMS sia al destinatario previsto che al server Web; il server Web verificherà quindi che l'MMS ricevuto sia stato effettivamente contrassegnato come "da inviare" anche al destinatario previsto. Ovviamente questo solleva molte domande su quanto sia sicura questa caratteristica multi-invio.

• Chiedi all'utente di firmare digitalmente il suo messaggio al server Web in cui è indicato che l'SMS è stato inviato . In questo modo, se viene scoperto che l'utente non ha effettivamente inviato l'SMS, allora ci saranno prove di slealtà dell'utente, in modo che tu possa denunciarlo. Questa "soluzione" consiste nel prevenire gli attaccanti di attaccare minacciandoli con pesanti ritorsioni legali.