Quali rischi per la sicurezza esistono nel trasferimento dati delle app del telefono cellulare?

Probabilmente il problema più diretto per quanto riguarda la sicurezza è la trasmissione di dati non crittografati. Ad esempio, immagina di utilizzare l'app di Facebook tramite Wi-Fi. Tuttavia, non sei il proprietario del gateway (cioè il router) o il tuo gateway è compromesso. Se i tuoi dati non sono crittografati in tale scenario, il tuo nome utente / password, le tue informazioni personali o anche le informazioni personali di altre persone sono alla mercé di qualcuno che annusa la rete.

Facebook, ovviamente, può essere considerato un rischio a bassa sicurezza, ma l'internet banking tramite smartphone è già possibile e le app non crittografano necessariamente i dati.

Un altro problema è il vettore stesso. Molti gestori usano ancora il GSM. Gli standard crittografici del GSM hanno più di 20 anni. Non solo le reti GSM possono essere violate, ma possono addirittura diventare ostaggi. Nuove implementazioni di GSM (noto anche come 2G) sono state sviluppate (UMTS / 3G) ma anche quelle sono state recentemente compromesse. Puoi leggere ulteriori informazioni su questo qui .

La tua domanda è un po 'vaga.

Quali dati vengono trasferiti dagli smartphone?

Dipende. Puoi essere abbastanza sicuro che i dati includeranno conversazioni telefoniche, messaggi SMS / MMS ed e-mail.

Quali dati sono memorizzati su uno smartphone?

• registra le chiamate (numero di telefono remoto, ora / data di inizio chiamata, durata della chiamata, direzione [in entrata / uscita], potenzialmente il nome del partecipante remoto
• Dati SMS / MMS (foto [data / ora, luogo, potenzialmente nomi di persone nelle foto])
• dati sulla posizione (ora / data con latitudine longitudine)
• foto (vedi SMS / MMS)
• e-mail (destinatari, ora / data, server pop3, server smtp)
• Utilizzo del sito web (URL, dati del modulo, cookie, data dell'ora dell'ultima visita)
• contatti (numeri di telefono, e-mail, indirizzo fisico, relazioni)
• musica (preferenze, frequenza di ascolto, ecc.)

Potenzialmente, tutti i dati memorizzati sullo smartphone potrebbero essere trasferiti.

Vuoi che questi dati siano privati (riservati)?

Se è così, allora i trasferimenti che coinvolgono questi dati devono essere protetti, di solito ciò avviene tramite crittografia. Il rischio per la sicurezza in questo caso sarebbe l'esposizione di dati riservati. La mitigazione dall'esposizione è la crittografia dei dati e la configurazione dei controlli di accesso per limitare l'accesso ai dati.

Vuoi proteggere qualcuno di questi dati dalla modifica?

I protocolli utilizzati durante il trasferimento dei dati hanno la capacità di modificare o cancellare i tuoi dati. Il rischio per la sicurezza in questo caso sarebbe la perdita di integrità dei dati (viene modificata), o la perdita di disponibilità dei dati (viene eliminata). La mitigazione contro la perdita di integrità è l'uso di hash crittografici (che indicheranno se i tuoi dati sono intatti o meno). Ulteriori misure di mitigazione potrebbero essere codici di correzione degli errori che consentono di recuperare i dati modificati. La mitigazione contro la perdita di disponibilità è il backup dei dati e il controllo degli accessi correttamente configurato. Il backup può ripristinare la disponibilità dei dati se viene distrutto e il controllo degli accessi può limitare chi può cancellare quali dati.

Un problema che è particolare, sebbene non esclusivo, per gli smartphone è la disponibilità del collegamento stesso. Se disponi di un'assegnazione di larghezza di banda limitata dal tuo operatore di rete mobile, un'app può eseguire prontamente l'intero dispositivo consumando l'intera allocazione.

Un problema correlato è che i servizi di dati MNO hanno maggiori probabilità di essere addebitati al punto di utilizzo rispetto alle connessioni wi-fi e addebitati a tariffe molto più elevate. È improbabile che agli utenti venga addebitato alcun costo per i dati utilizzati da un'app botnet o spyware.

La risposta varia a seconda del protocollo wireless utilizzato.

• GSM: consulta Smartphone / GSM Sniffer per i dettagli su recenti interruzioni delle comuni crittografie GSM 2G (EDGE / GPRS).

• CDMA, LTE: vedere Qual è l'albero di attacco per intercettare il traffico su 4G e 3G? per seguire gli attacchi riportati a DEFCON 2011.

• Wi-fi WPA2: vedere Come funziona FaceNiff? - Sicurezza IT - Stack Exchange per attacchi a WPA2.

Vedi puoi garantire un web app da FireSheep senza usare SSL? per il motivo per cui dovresti semplicemente usare SSL / TLS per proteggere i dati sensibili da tutte queste cattive implementazioni wireless, oltre alle vulnerabilità nelle reti cablate.

Gli attacchi al canale possono verificarsi se le informazioni non sono crittografate, poiché si tratta di un mezzo di trasmissione. Inoltre, non hai il controllo dell'antenna, quindi se potrebbe essere compromessa potresti anche essere suscettibile di attaccare lì.

Soluzione - canale crittografato e autenticato. E questo vale per WiFi o GSM - se non è la tua rete, non fidarti affatto; se lo è, assicuralo agli altri e proteggiti ancora.

Anche la negazione del servizio è un attacco molto probabile, dal momento che qualsiasi comunicazione wireless è soggetta a interferenze.

Soluzione - non molto che puoi fare qui se un attaccante ha un jammer ad alta potenza

Per aggiungere alle altre risposte qui, non dimenticare che la rete di backhaul è almeno tanto un problema quanto il collegamento aereo, se non di più. C'è stata una buona presentazione a Shmoocon 2011 da parte di Enno Rey di ERNW (che lavora molto in quest'area, bravi ragazzi) mostrando alcuni dei loro risultati in quest'area.

Un sacco di posti per andare male ... meglio solo per supporre che i servizi dati cellulari siano equivalenti al wi-fi pubblico e comportarsi di conseguenza.

I rischi per la sicurezza che esistono sulle applicazioni dei telefoni cellulari nel processo di trasferimento dei dati sono esattamente identici ai rischi associati, ad esempio, al portatile personale nel processo di trasferimento dei dati. Molte volte tendiamo a pensare che i problemi relativi alle applicazioni mobili siano troppo diversi perché si tratta di una rete diversa.

Diciamo per esempio che uno ha collegato il suo laptop per navigare su Facebook o GMAIL usando la rete WIFI aperta o una rete aziendale. Il rischio associato è lo stesso rispetto alla comunicazione con le applicazioni mobili. Qualcuno nella rete aziendale o nella rete WIFI aperta può annusare i dati che vengono trasmessi. Per quanto riguarda i siti bancari, oggi è difficile crederci se esiste un accesso al portale bancario in cui l'intera sessione non è abilitata alla crittografia SSL. In effetti, GMAIL ora supporta la sessione con registrazione completa su SSL. Google ha esteso lo stesso anche per il motore di ricerca utilizzando il link

L'applicazione Facebook o l'applicazione GMAIL potrebbero non sapere nemmeno quale sia il tipo di connessione Internet che è in uso. Ad esempio se l'app è l'applicazione J2ME, l'applicazione non ha API esposte per determinare la modalità di connessione a Internet. Nel blackberry le applicazioni possono saperlo. In Android e IPhone potrebbe essere possibile.

Nella normale comunicazione mondiale per PC, ci affidiamo all'SSL, quindi lo stesso deve essere implementato anche nelle applicazioni mobili. Quindi non c'è differenza.

Il rischio associato alle applicazioni mobili nelle mie visualizzazioni sono applicazioni di terze parti come quelle fornite usando quali servizi puoi eseguire su Facebook o controllare i tuoi messaggi. Possono avere il codice o il malware sbagliato che potrebbero esporre i dati ad altri server. Quindi tutto dipende dal fattore di fiducia che abbiamo con il fornitore di software.

In realtà in qualche modo le app mobili sono protette rispetto alle sessioni del browser come nelle app mobili, si possono applicare regole forti su quale certificato server deve essere accettato nel processo dell'handshake SSL che nel normale mondo PC potrebbe essere compromesso in uomo in attacco medio confondendo l'utente finale con un certificato di spook e un sito Web simile.