proteggere l'accesso a una risorsa remota

[blackskop]

Salve, ho un problema curioso che non riesco a risolvere o perchè non conosco bene le tecnologie che potrebbero risolverlo o perchè la natura del problema è un'altra da quella che credo.


Ho una risorsa A remota a cui può accedere un'applicazione B remota.

In realtà la risorsa A è visibile anche all'esterno dell'applicazione B.

Vorrei fare in modo che la risorsa A sia in grado di discrimiare se l'accesso è stato effettuato dall'applicazione B o da un'applicazione C sconosciuta.

Come prima soluzione banale mi è venuta in mente quella di inviare un identificativo all'atto dell'accesso:

A accetta le richieste controllando che l'id della richiesta sia uguale a 1.
B accede ad A inviando l'id 1.
C, che non conosce la chiave, non può accedere ad A.

Se però qualcuno è in grado di fare reverse di B, può anche scoprire qual è la chiave ed accedere ad A tramite C (utilizzando appunto la chiave trovata).

Usando questa metodologia, c'è un modo per evitare un attacco del genere?


Altrimenti, esiste un'altra metodologia che mi risolve il problema?

[fero86]

la strategia che tu proponi consiste banalmente nell'uso di una password o di una chiave crittografica simmetrica.
con le informazioni che ci dai non siamo in grado di suggerirti soluzioni migliori, hai posto il problema in maniera troppo astratta, peró provo comunque a suggerire SSL/TLS: SSL/TLS infatti supporta anche l'autenticazione del client, che a quanto sembra é proprio il tuo problema (vuoi che B sia in grado di distinguere A da C).

[k0nt3]

se stai parlando di una rete locale probabilmente la soluzione migliore è mettere la macchina su cui gira A dietro un firewall che forwarda solo i pacchetti provenienti dalla macchina su cui è presente B.
in questo modo però è sempre possibile accedere ad A da una qualsiasi applicazione C installata sulla macchina di B. ma non è possibile da applicazioni che girano su altre macchine. è un problema?

[blackskop]

Originariamente inviato da fero86

la strategia che tu proponi consiste banalmente nell'uso di una password o di una chiave crittografica simmetrica.
con le informazioni che ci dai non siamo in grado di suggerirti soluzioni migliori, hai posto il problema in maniera troppo astratta, peró provo comunque a suggerire SSL/TLS: SSL/TLS infatti supporta anche l'autenticazione del client, che a quanto sembra é proprio il tuo problema (vuoi che B sia in grado di distinguere A da C).

Puoi fare un esempio della logica di funzionamento di SSL/TLS ?

[blackskop]

Originariamente inviato da k0nt3

se stai parlando di una rete locale probabilmente la soluzione migliore è mettere la macchina su cui gira A dietro un firewall che forwarda solo i pacchetti provenienti dalla macchina su cui è presente B.
in questo modo però è sempre possibile accedere ad A da una qualsiasi applicazione C installata sulla macchina di B. ma non è possibile da applicazioni che girano su altre macchine. è un problema?

Sei sceso gia nei dettagli. Volevo capire se il problema si poteva affrontare prima a livello logico.
Comunque la tua soluzione non va bene perchè è proprio questo il caso che mi interessa: un utente si siede davanti alla macchina abilitata, fa il reverse dell'applicazione B, trova la chiave, lancia dalla stessa macchina l'applicazione C con la giusta chiave.

Il problema può essere rappresentato anche con un esempio non informatico:

Un mio amico (A) e io (B) ci scriviamo le lettere. Dato che anche mio fratello (C) conosce l'indirizzo del mio amico, potrebbe benissimo scrivergli fingendosi me. Allora A e B decidono di aggiungere una frase particolare in ogni lettera per essere sicuri delle loro identità. Ma se mio fratello scopre la frase magica?

Un modo per impedirgli di scoprirla è non scriverla da nessuna parte, tranne che nella lettera (tenerla stampata nel cervello quindi).

Così funzionerebbe sempre. Mio fratello non può fare il reverse del mio cervello.

Ma traportando l'esempio nell'ambito informatico, come posso proteggere una password scritta da qualche parte dal reverse engineering?

[k0nt3]

la soluzione al tuo problema è usare algoritmi di crittografia asimmetrica. nel mio esempio ovviamente davo per scontato che il computer su cui girava B era fidato, cioè non potesse fare cose non previste

[fero86]

Originariamente inviato da blackskop

Ma traportando l'esempio nell'ambito informatico, come posso proteggere una password scritta da qualche parte dal reverse engineering?

potresti chiuderla a chiave nel TPM e nasconderla tramite memory curtaining quando la prelevi; in pratica dovresti far uso della tecnologia tanto bistrattata da k0nt3 cosi come da Stallman e da un sacco di altre persone, ovvero il Trusted Computing

tralasciando il Trusted Computing e tornando ad SSL, leggendo ció che hai aggiunto non sono piu sicuro che sia sufficiente. chiariamo un aspetto importante: a te interessa negare l'accesso alla risorsa da parte di determinati utenti, da parte di determinati host o da parte di determinati programmi? la terza non mi pare che abbia molto senso: se il programma C viene eseguito da un utente che ha pieno diritto di accesso alla risorsa non vedo che male ci sia.

per quanto riguarda le altre due: per negare l'accesso ad utenti non autorizzati di solito si usa una password inserita dall'utente, quindi una password non hard-coded che un cracker non puó ricavare facendo reverse engineering; mentre nel secondo caso dovresti poter assumere che gli host che hanno diritto di accedere alla risorsa siano identificabili da un nome univoco, come un IP statico o un nome DNS.

[blackskop]

Originariamente inviato da fero86

potresti chiuderla a chiave nel TPM e nasconderla tramite memory curtaining quando la prelevi; in pratica dovresti far uso della tecnologia tanto bistrattata da k0nt3 cosi come da Stallman e da un sacco di altre persone, ovvero il Trusted Computing

Così è semplice, lasciamo da parte il TC.

Originariamente inviato da fero86

tralasciando il Trusted Computing e tornando ad SSL, leggendo ció che hai aggiunto non sono piu sicuro che sia sufficiente. chiariamo un aspetto importante: a te interessa negare l'accesso alla risorsa da parte di determinati utenti, da parte di determinati host o da parte di determinati programmi? la terza non mi pare che abbia molto senso: se il programma C viene eseguito da un utente che ha pieno diritto di accesso alla risorsa non vedo che male ci sia.

per quanto riguarda le altre due: per negare l'accesso ad utenti non autorizzati di solito si usa una password inserita dall'utente, quindi una password non hard-coded che un cracker non puó ricavare facendo reverse engineering; mentre nel secondo caso dovresti poter assumere che gli host che hanno diritto di accedere alla risorsa siano identificabili da un nome univoco, come un IP statico o un nome DNS.

Dunque, cerco di illustrare meglio il problema.

A è la risorsa, che può essere usata sia da B, che è una specifica applicazione utilizzata a sua volta da un utente C che quindi indirettamente sfrutta A.

In realtà C potrebbe bypassare B accedendo direttamente ad A (realizzando un altro programma), vanificando di fatto il compito di B.

Il flusso di esecuzione non sarebbe più C -> B -> A ma C -> B1 -> A


Io (C) voglio prelevare soldi dal bancomat (A) solo se il direttore della banca (B) mi da il permesso di prelevare. Se io C però vado al bancomat, riesco a prelevare ugualmente i soldi perchè di fatto ho bypassato il controllo di B.

Direi quindi che a me interessa negare l'accesso a determinati programmi.


Utilizzando le tue parole, a me interessa

negare l'accesso ad applicazioni non autorizzate, utilizzando una password hard coded ma non identificabile da reverse

[k0nt3]

Originariamente inviato da blackskop

Utilizzando le tue parole, a me interessa

negare l'accesso ad applicazioni non autorizzate, utilizzando una password hard coded ma non identificabile da reverse

impossibile. qualsiasi password hard coded è identificabile mediante reverse (sarebbe abbastanza facile un attacco di tipo replay).
l'unica cosa che puoi fare è usare la crittografia asimmetrica:

MITTENTE (B): prendi il messaggio che devi mandare ad A e con una funzione di hash generi un digest. cripti il digest con la chiave privata (di B) e ottieni una firma digitale. adesso prendi ancora il messaggio originale, gli appendi la firma digitale e il tutto lo cripti con la chiave pubblica di A.

DESTINATARIO (A): prendi il messaggio ricevuto e lo decripti con la chiave privata (di A). ottieni il testo in chiaro con la firma digitale appesa alla fine. ora prendi il messaggio in chiaro e con la stessa funzione di hash usata da B generi un digest. infine prendi la firma digitale e la decripti con la chiave pubblica di B ottenendo il digest originale (calcolato da B). confronti i due digest, se sono uguali allora sei sicuro che il messaggio l'hai ricevuto da B.

per la comunicazione in senso opposto si fa la stessa cosa (dove al posto delle chiavi di B si usano quelle di A e viceversa)

in tutto questo è necessario che sia A che B dispongono di una chiave pubblica e di una privata. la chiave pubblica può essere nota a tutti che non è un problema, mentre la chiave privata DEVE essere nascosta. qui dovresti poterla nascondere con una gestione dei permessi locale nel pc dove gira B.
per evitare attacchi di tipo replay ti consiglio di mettere nel messaggio che B manda a A anche un numero abbastanza grosso che non si deve ripetere (se non a grande distanza di tempo). a questo punto quando A riceve il messaggio controlla anche che non sia stato già mandato un messaggio con quel numero. in tal caso sicuramente il messaggio non è stato mandato da B.

potresti chiuderla a chiave nel TPM e nasconderla tramite memory curtaining quando la prelevi; in pratica dovresti far uso della tecnologia tanto bistrattata da k0nt3 cosi come da Stallman e da un sacco di altre persone, ovvero il Trusted Computing

non diciamo cose che non si conoscono
il trusted computing è una tecnologia utile in ambito aziendale, quello che NON voglio vedere sono i suoi utilizzi in ambito desktop per fare i porci comodi di certe multinazionali.

[gugoXX]

Originariamente inviato da k0nt3

il trusted computing è una tecnologia utile in ambito aziendale, quello che NON voglio vedere sono i suoi utilizzi in ambito desktop per fare i porci comodi di certe multinazionali.

Ad esempio?

[blackskop]

Originariamente inviato da k0nt3

impossibile. qualsiasi password hard coded è identificabile mediante reverse (sarebbe abbastanza facile un attacco di tipo replay).
l'unica cosa che puoi fare è usare la crittografia asimmetrica:

MITTENTE (B): prendi il messaggio che devi mandare ad A e con una funzione di hash generi un digest. cripti il digest con la chiave privata (di B) e ottieni una firma digitale. adesso prendi ancora il messaggio originale, gli appendi la firma digitale e il tutto lo cripti con la chiave pubblica di A.

DESTINATARIO (A): prendi il messaggio ricevuto e lo decripti con la chiave privata (di A). ottieni il testo in chiaro con la firma digitale appesa alla fine. ora prendi il messaggio in chiaro e con la stessa funzione di hash usata da B generi un digest. infine prendi la firma digitale e la decripti con la chiave pubblica di B ottenendo il digest originale (calcolato da B). confronti i due digest, se sono uguali allora sei sicuro che il messaggio l'hai ricevuto da B.

per la comunicazione in senso opposto si fa la stessa cosa (dove al posto delle chiavi di B si usano quelle di A e viceversa)

in tutto questo è necessario che sia A che B dispongono di una chiave pubblica e di una privata. la chiave pubblica può essere nota a tutti che non è un problema, mentre la chiave privata DEVE essere nascosta. qui dovresti poterla nascondere con una gestione dei permessi locale nel pc dove gira B.
per evitare attacchi di tipo replay ti consiglio di mettere nel messaggio che B manda a A anche un numero abbastanza grosso che non si deve ripetere (se non a grande distanza di tempo). a questo punto quando A riceve il messaggio controlla anche che non sia stato già mandato un messaggio con quel numero. in tal caso sicuramente il messaggio non è stato mandato da B.

non diciamo cose che non si conoscono
il trusted computing è una tecnologia utile in ambito aziendale, quello che NON voglio vedere sono i suoi utilizzi in ambito desktop per fare i porci comodi di certe multinazionali.

Il problema in questo modo non si è spostato perchè per proteggere una password in una zona protetta della macchina locale, devo usare una password... o no?

Anche riuscendoci poi basterebbe smontare l'hd e leggere il file che contiene la password bypassando il sistema operativo.

Inoltre, tutto sto casino si può bypassare andando a fare il dump della memoria nel momento in cui si va a leggere la pass dalla macchina locale.

Questo approccio non funziona. Bisognerebbe trovare un altra metodologia.

Un'altra a cui ho pensato è una sorta di protezione a livello di stato.

Mi spiego, il mittente B, prima di utilizzare la risorsa A, deve aver fatto delle operazioni sulla risorsa C, F, G.

Nel momento in cui viene utilizzata A, essa stessa verifica che l'utente abbia fatto accesso ad altre risorse in una sequenza prestabilita, sequenza che è dettata dall'applicazione usata dal mittente e che può quindi essere offuscata.

Anche questa metodologia non garantisce la sicurezza, ma grazie all'offuscamento, capire la logica con cui viene effettuata la sequenza di accessi alle verie risorse può essere complicato.

[k0nt3]

Originariamente inviato da gugoXX

Ad esempio?

ad esempio con il TC è possibile che un'applicazione crei dei documenti non leggibili da altro software indipendentemente dal formato utilizzato.
comunque qui è OT

[k0nt3]

Originariamente inviato da blackskop

Il problema in questo modo non si è spostato perchè per proteggere una password in una zona protetta della macchina locale, devo usare una password... o no?

Anche riuscendoci poi basterebbe smontare l'hd e leggere il file che contiene la password bypassando il sistema operativo.

Inoltre, tutto sto casino si può bypassare andando a fare il dump della memoria nel momento in cui si va a leggere la pass dalla macchina locale.

Questo approccio non funziona. Bisognerebbe trovare un altra metodologia.

Un'altra a cui ho pensato è una sorta di protezione a livello di stato.

Mi spiego, il mittente B, prima di utilizzare la risorsa A, deve aver fatto delle operazioni sulla risorsa C, F, G.

Nel momento in cui viene utilizzata A, essa stessa verifica che l'utente abbia fatto accesso ad altre risorse in una sequenza prestabilita, sequenza che è dettata dall'applicazione usata dal mittente e che può quindi essere offuscata.

Anche questa metodologia non garantisce la sicurezza, ma grazie all'offuscamento, capire la logica con cui viene effettuata la sequenza di accessi alle verie risorse può essere complicato.

l'utente che lavora sulla macchina su gira B deve necessariamente avere un accesso limitato alla macchina, altrimenti non c'è modo di fare quello che chiedi.
la sicurezza tramite l'offuscamento è una delle cose peggiori che può venire in mente a uno che progetta un sistema di sicurezza. la storia insegna che non funziona

[blackskop]

Originariamente inviato da k0nt3

l'utente che lavora sulla macchina su gira B deve necessariamente avere un accesso limitato alla macchina, altrimenti non c'è modo di fare quello che chiedi.

Spiegati meglio.

Ho capito, ma questa è una condizione che non è possibile soddisfare. Perciò dicevo che l'approccio con protezione da password non può funzionare e bisognerebbe trovare un'altra metodologia.

[k0nt3]

Originariamente inviato da blackskop

Spiegati meglio.

deve avere un account limitato per esempio. non può accedere a certe risorse, non può eseguire certe azioni ecc..
questo dipende dal sistema operativo e dalla gestione dei permessi su quella macchina.
per evitare che possa portarsi via l'hard disk potresti utilizzare una partizione criptata.
cioè non so il livello di sicurezza che ti serve ma puoi rendere arbitrariamente difficile il compito di un malintenzionato.
certo che sarebbe molto più semplice se l'utente che utilizza B lo fa da remoto (cioè da C), quindi non dalla stessa macchina. e A accetta solo le richieste che arrivano dalla macchina su cui gira B (e a quella macchina non ci accede nessuna persona non fidata).

[k0nt3]

se vuoi usare il metodo dell'offuscamento la cosa più semplice è creare una password in maniera complicata all'interno dell'applicazione, ma alla fine, se uno si mette a osservare il traffico di rete, basta che riproduce le stesse sequenze di trasmissione per comunicare con A. cioè facendo reverse engineering sul protocollo di comunicazione

[gugoXX]

Originariamente inviato da k0nt3

ad esempio con il TC è possibile che un'applicazione crei dei documenti non leggibili da altro software indipendentemente dal formato utilizzato.
comunque qui è OT

Un modo come per dire semplicemente che quel formato e' proprietario...
Comunque sono interessato, apriamo pure una discussione.

[k0nt3]

Originariamente inviato da gugoXX

Un modo come per dire semplicemente che quel formato e' proprietario...
Comunque sono interessato, apriamo pure una discussione.

se vuoi aprila e linkamela, io tra 5 minuti finisco il mio tempo disponibile sul forum ma parteciperò senz'altro alla discussione quando ho tempo

[cionci]

Originariamente inviato da blackskop

Nel momento in cui viene utilizzata A, essa stessa verifica che l'utente abbia fatto accesso ad altre risorse in una sequenza prestabilita, sequenza che è dettata dall'applicazione usata dal mittente e che può quindi essere offuscata.

Anche questa metodologia non garantisce la sicurezza, ma grazie all'offuscamento, capire la logica con cui viene effettuata la sequenza di accessi alle verie risorse può essere complicato.

Monitoro le risorse di A a livello di sistema operativo o accesso ai file ed ottengo la sequenza.
Se si va avanti ci sarà sempre la possibilità di bypassare la protezione.
Ad esempio anche con il TC, supponendo che io abbia accesso all'hardware...estraggo il chip di TC, simulo il funzionamento di B ed ottengo la mia risposta

Non c'è e probabilmente non ci sarà mai la sicurezza assoluta se uno fra A e B non è al sicuro dall'intervento hardware/software dell'attaccante.

[fero86]

Originariamente inviato da k0nt3

non diciamo cose che non si conoscono

e cosa avrei detto che non conosco?

gugo, dov'é quel topic? interessa anche a me.