Comunicazione sicura tra due applicazioni sullo stesso sistema

8

Sto scrivendo un software che è diviso in due parti separate separate. Uno è un servizio come l'applicazione che gestisce tutte le logiche, l'altra è un'applicazione GUI che funziona come un front-end e che è destinata ad essere utilizzata dall'utente finale. Il servizio ascolta una porta e accetta richieste dall'applicazione client (GUI).

Poiché alcune informazioni sensibili vengono scambiate tra il servizio e le applicazioni della GUI, devono essere crittografate prima di essere trasferite. Un modo per proteggere i dati è utilizzare una crittografia basata su chiave, ma le chiavi devono essere memorizzate da qualche parte sul disco o anche nel codice sorgente dell'applicazione, ma preferiscono evitare l'uso di chiavi.

Come posso gestire una connessione sicura tra servizio e applicazione GUI senza utilizzare un algoritmo di crittografia basato su chiave?

    
posta sepisoad 27.02.2015 - 09:01
fonte

3 risposte

14

Queste sono la regola d'oro della sicurezza informatica: "È impossibile nascondere qualsiasi cosa da un utente competente con privilegi di amministratore di sistema" e "qualsiasi utente competente con accesso fisico al dispositivo può sempre elevarsi all'amministratore di sistema".

Non puoi nascondere alcuna informazione da qualcuno con il controllo fisico della macchina. Se il segreto che stai cercando di nascondere è davvero importante, non dovresti mai trasferire i dati sulla macchina ed eseguire l'elaborazione altrove in un posto che controlli.

Il tuo programma è in esecuzione sul computer di un utente. Non puoi proteggere i tuoi dati dall'utente. Con questo in mente, significa che siamo condannati? Non necessariamente. Il sistema operativo fornisce un ampio meccanismo per i programmi per comunicare in privato con un altro programma che non consentirà a un'altra applicazione non privilegiata di intercettarlo. Pertanto, sebbene non sia possibile proteggere i dati dall'utente stesso, è possibile proteggere i dati da un altro programma non privilegiato. Fornire un limite di sicurezza tra i programmi non privilegiati è uno dei compiti principali dei sistemi operativi.

Il più semplice di questo è un pipe anonimo. Una pipe consente di trasportare un flusso unidirezionale di dati tra un programma e l'altro. La pipe anonima è disponibile in Windows, Linux, OSX e tutti i sistemi di tipo Unix. La pipe anonima è più comunemente riconosciuta come una coppia di pipe denominata stdin e stdout che consente a un processo padre di inviare e ricevere un flusso di dati da e verso i propri figli. La pipe anonima può essere utilizzata solo tra processi che hanno relazioni parent e child. C'è anche una named pipe, ma si comportano diversamente in Windows e nei sistemi Linux / Unix, torneremo su questo più tardi.

Un altro IPC comunemente disponibile è socket. Gli zoccoli sono come una pipa bidirezionale. Ci sono molte prese diverse ma funzionano allo stesso modo. Il più conosciuto è il socket TCP. Il socket TCP è principalmente inteso per il collegamento in rete tra macchine, ma è anche possibile creare un socket TCP di loopback che può essere utilizzato solo all'interno della stessa macchina. Un socket di loopback fornisce privacy (solo il programma che il programma si connette e il programma che ascolta può leggere i dati che passano attraverso il socket), ma in realtà non fornisce un meccanismo per limitare chi può essere l'altro lato del socket.

Un altro tipo di socket disponibile in Unix per la comunicazione tra i processi nella stessa macchina è Unix Domain Socket. Un socket di dominio Unix viene esposto ai programmi come "file speciale" nel filesystem, e l'autorizzazione del file system unix viene utilizzata per controllare l'accesso al socket. Non è possibile collegare un socket di dominio a programmi che non dispongono dell'autorizzazione di accesso per accedere al file socket. Nei sistemi di tipo Unix, questo significa che il tuo servizio e la GUI dovrebbero essere eseguiti come lo stesso utente e / o gruppo che sono riservati solo per il tuo programma e hai impostato il permesso del file socket in modo appropriato.

Torniamo alla pipe denominata. Nei sistemi Linux / Unix, una pipe denominata è simile a stdin / stdout in quanto sono unidirezionali. In Windows, tuttavia, una pipe denominata è in realtà bidirezionale ed è praticamente l'equivalente del socket di dominio Unix in Windows. Come molte cose in Windows, named pipe è protetto con ACL.

Con iOS le cose diventano un po 'pelose. Un iOS non jailbroken consente solo un insieme limitato di molto di comunicazione tra processi e nessuno dei due darà un socket. Ma se giochiamo liberamente con la definizione, nell'applicazione iOS, il programma di servizio e il programma GUI probabilmente diventeranno la stessa applicazione, quindi è possibile semplicemente creare uno stream direttamente tra diversi componenti dell'applicazione. Questo è anche sicuro poiché lo streaming è accessibile solo all'interno dell'applicazione.

Android offre più opzioni per IPC, inclusa la possibilità di creare socket di dominio. L'API è diversa ma concettualmente simili con il normale Linux. In alternativa, è possibile seguire lo stesso approccio come in iOS e impacchettare il servizio e la GUI nella stessa applicazione e utilizzare solo flussi in-process.

    
risposta data 27.02.2015 - 18:19
fonte
1

Presumo che tu sia l'unico root / amministratore sulla macchina.

Puoi utilizzare una di queste due opzioni:

  1. Non consentire assolutamente ad altri utenti su quella macchina
  2. Lascia che il processo venga eseguito come utente speciale e utilizzi un meccanismo di comunicazione accessibile solo (lettura + scrittura) a tale utente (named pipe, unix domain socket, ecc.)

Qualsiasi di queste due opzioni renderà non necessario crittografare i tuoi dati durante il transito.

Nota: se nella macchina è presente un altro amministratore (sufficientemente qualificato), non è possibile nascondere nulla (incluse le chiavi di crittografia).

    
risposta data 27.02.2015 - 16:09
fonte
0

Fondamentalmente, la sicurezza è generalmente supportata dalla chiave, non dall'algoritmo. Quindi sei in missione sciocca qui. Come affermato dal principio di Kerckhoff: "Un criptosistema dovrebbe essere sicuro anche se tutto ciò che riguarda il sistema, ad eccezione della chiave, è di dominio pubblico.", O come Shannon lo ha riformulato: "il nemico conosce il sistema". Quindi non puoi davvero avere un criptosistema che non usi una chiave in qualche modo e sia davvero sicuro.

Dato che hai menzionato nella tua lista di tag, lascia che ti ricordi come questo lavoro in linea di principio.

L'idea di SSL / TLS (https) è di negoziare una chiave di crittografia simmetrica da utilizzare per una sessione di comunicazione tra un client e un server. Il client si connette al server e richiede la sua chiave pubblica (crittografia asimmetrica). La chiave viene fornita come parte di un certificato, che può essere convalidato utilizzando la catena di certificazione del certificato. Con quella chiave pubblica e una corretta convalida del certificato, il cliente sa a chi sta parlando. Così può tranquillamente trasmettere informazioni.

Il client può quindi utilizzare la chiave pubblica per negoziare una chiave simmetrica per parlarsi l'un l'altro per questa sessione. La chiave non può essere derivata per nessuno al di fuori della comunicazione (fare riferimento a spiegazioni più dettagliate se necessario link )

Con l'uso di TLS, la riservatezza è garantita tra i due partner e il client può anche autenticare il server utilizzando la catena di certificazione. Se è necessario autenticare i client, TLS supporta anche il certificato dei client.

    
risposta data 27.02.2015 - 09:38
fonte

Leggi altre domande sui tag