Protezione del contenuto di un file basata su password

Questa pagina contiene approfondimenti credo "molto interessanti" ma che non sono parte del programma di esame.

Requisito e Motivazione

E' spesso necessario proteggere l'accesso in lettura ad un file tramite password (ad esempio quando il file contiene una chiave crittografica).

Più precisamente, dato un file F su cui l'utente autenticato U ha permesso di lettura, si desidera imporre un vincolo aggiuntivo:

U può comprendere il contenuto di F solo se dimostra la conoscenza di una password P(F) (password del tutto indipendente da quella che U ha usato per autenticarsi con il sistema operativo e che è specifica di F, cioè è usata solo per accedere ad F).

Questo meccanismo difensivo è un esempio di un principio più generale ed estremamente importante (non solo in Cybersecurity) chiamato Defense In Depth. In parole poverissime, la difesa non deve mai basarsi su un singolo meccanismo; deve basarsi sempre su meccanismi multipli ed indipendenti: la tecnica per superare un meccanismo non permette di superare il meccanismo successivo. In questo modo, se un attaccante riesce a superare una difesa, deve ripetere lo sforzo per superare la difesa successiva (ed eventualmente quella ancora successiva).

Nel caso specifico, un attaccante può riuscire ad impersonare U (ad esempio perché ha ottenuto la password con cui U si autentica nei confronti del sistema operativo). Lo sforzo di attacco con cui l'attaccante ha impersonato U non è però sufficiente per per permettergli di accedere ad F.

Realizzazione

Ogni accesso ad F deve essere mediato da un software di verifica S che deve ricevere tra i propri parametri di input F e P(F).

Ad esempio, per accedere tramite openssl ad un file contenente una chiave privata occorre passare ad openssl il nome del file e la password corrispondente.

I dettagli realizzativi di questo meccanismo di protezione non fanno parte di questo corso. Non sono banali: come fa S a conoscere la password corretta? Tentativo di risposta: la memorizza in F; ciò non funzionerebbe perché in tal caso chi ha diritto di accesso in lettura al file potrebbe leggerne il contenuto e quindi ottenere la password.

Intuitivamente, e solo per avere un'idea, il meccanismo è indicato di seguito (per comprendere questo meccanismo è necessario conoscere gli operation mode e le proprietà di sicurezza corrispondenti, spiegate in Approfondimenti_Network_Security):

Quando viene creato F, viene scelta una password P(F).
Dalla password P(F) viene derivata una chiave crittografica KP(F) con un algoritmo pubblico, deterministico e tale che password diverse generano password diverse.
Il file F viene crittato con la chiave KP(F) utilizzata in un operation mode che garantisce secrecy, authentication e integrity.

A questo punto il contenuto di F è incomprensibile (secrecy): in utente che ha il diritto di accedere ad F in lettura potrebbe bypassare il software di verifica S, ma il contenuto di F sarebbe incomprensibile.

Per comprendere il contenuto di F è necessario fornire una password al software di verifica S, indichiamola con P1. S deriva da P1 una chiave KP1 e decritta F con questa chiave KP1. Se la decrittazione ha successo allora è matematicamente certo che KP1=KP(F) (autenticazione); è anche certo per le proprietà dell'algoritmo di derivazione chiave da password che P1=P(F), cioè la password P1 con la quale si sta accedendo al file è effettivamente la stessa password P(F). Inoltre, è matematicamente certo che il contenuto di F non è stato modificato rispetto a quando è stato creato (integrity).

Notare che:

Il meccanismo di protezione non richiede nessun "database delle credenziali" o funzionalità specifiche del sistema operativo.
La password non è memorizzata da nessuna parte (quindi se ci si dimentica la password allora non c'è modo di utilizzare il file corrispondente; si può solo procedere per tentativi con tante password sperando di trovare la password corretta).
Accedere al file in lettura, cioè bypassando il software di verifica che richiede l'uso della password, è inutile in quanto il contenuto del file è crittato quindi incomprensibile.

Ed i Server?

Rimane un ulteriore problema, molto importante.

Se S viene usato solo quando un operatore sta usando il calcolatore in modo interattivo, allora l'inserimento della password è semplice: l'utente la scrive da tastiera. Ma se S deve poter accedere al contenuto di F anche senza la presenza fisica di un operatore (ad esempio quando S è invocato da un web server) allora il problema è complicato: chi inserisce la password? Non può farlo nessun operatore, perché l'operatore non c'è.

Tentativo: La password potrebbe essere memorizzata in un altro file FP ed S potrebbe ricevere come input il nome del file FP da cui leggere la password.

A questo punto però torniamo esattamente allo stesso problema iniziale: FP deve essere accessibile in lettura all'utente U associato al server; quindi un attaccante che impersona U può leggere la password contenuta in FP; occorre quindi una ulteriore password per proteggere FP: ma chi inserisce questa ulteriore password in assenza di operatore?

Altro tentativo: la password potrebbe essere specificata come parametro di ingresso di S.

In questo caso per mandare in esecuzione S occorre codificarne l'invocazione in uno script che sarà lanciato automaticamente dal sistema operativo. Questo script deve essere leggibile dall'utente U associato al server: stesso problema!

Il modo con il quale devono essere memorizzati i segreti nei programmi (ad esempio le password) non è discusso qui.