Newsgroup: it.comp.os.linux.iniziare
Titolo: chiave hardware univoca e stabile

Ho bisogno di una chiave, per un criptare una password. Me ne sto
inventando una paranoica, ma supersicura.
Da come la sto facendo (mi sto sbizarrendo un po') viene fuori una
chiave a prova di furto del pc (peccato che non sia a prova di furto
quello che deve essere protetto dalla password :-)
Per avere una chiave sicura credo questi punti possano andar bene:
1) non può essere generata da utente semplice.
2) che non vada memorizzata su hd, di modo che non si rischi che questa
venga backuppata
3) deve essere strettamente legata all'hardware
4) la chiave non deve variare con reboot o qualsiasi altro evento non
controllabile
5) [prova di furto 1] non deve essere qualcuno che faccia boot cdrom
(perchè non sa la password di root) riesca a rigenerare la chiave
6) [prova di furto 2] non deve essere qualcuno che resetti la password
di root riesca a generare la chiave
ovviamente qualsiasi uno dei punti sopra viene a mancare (cambio
hardware o cambio password di root) io devo poter rigenerare (a mano) la
chiave
Ho pensato a questo:
A=$(dmidecode)      # per legarla all'hardware
B=$(cat /proc/partitions |grep hd[a-z]$|awk '{print $4}'|xargs -i dd
if=/dev/{} count=1 2>/dev/null) # per legarla anche ai dischi
C=$(cat /proc/cmdline)          # per impedire il boot cdrom
D=$(head -1 /etc/shadow)        # per ovviare al reset passw. di root
CHIAVE=$(echo $A$B$C$D|md5sum|cut -c-32)
$CHIAVE mi sembra abbastanza univoca, non generabile da utente, non
generabile su un altro pc, e tutto quello che avevo detto sopra.
ora devo criptare la password in modo _reversibile_ in modo che dalla
password cripata con $CHIAVE possa risalire alla password.
credo che il più semplice sia una funzione tipo
PASSCRIPTATA=$CHIAVE xor $PASSWORD
ma è abbastanza sicuro?
C'è già un algoritmo del genere o mi devo fare anche quello?
Matteo
P.S. tutto questo è paranoia, ma serve sicuramente per imparare qualcosa
(in effetti proteggere una porticina di vetro con un lucchetto immenso e
serratura a lettura ottica, non credo che serva a molto)
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 password cripata con $CHIAVE possa risalire alla password.
]zac[
Questo introduce un discreta insicurezza, solo gli algoritmi non reversibili
hanno qualche speranza di non essere 'rompibili'.
Di solito la risposta è 'voglio solo proteggermi dai normali utenti', beh in
quel caso non servono cose complicate.
In sintesi con i power user gli algoritmi reversibili li vedo piuttosto
indifesi.
Non sarebbe più facile, sempre che esistano anche per linux, usare una
chiave hardware, magari su usb, costano poco, molte sono molto flessibili,
difficilmente aggirabili (a parte rimuovendo il codice che effettua i
controlli, ma questo vale per qualsiasi cosa non strettamente hardware).

 ma č abbastanza sicuro?
qualsiasi protocollo reversibile non e' sicuro per definizione.
Abbastanze sicuro per lo scopo a cui dedichi lo studio, si.
Un pc che si ruba credo che venga immediatamente formattato, quindi,
chiave o non chiave....

 
Questo è vero, però l'algoritmo irreversibile ha un il suo limite, ed è
quello di stabilire se la password inserita è corretta o meno.
A me questo non basta. Il mio scopo è fare uno script che si logghi dentro
un programma fornendogli utente e password; quindi lo script deve conoscere
la password.
In fondo, se non erro, anche openssh utilizza un algoritmo reversibile
criptato con chiave irreversibile. E mi sembra di aver capito che se
qualcuno riesce a sniffare la chiave in teoria può decriptare anche il
traffico di dati che riesce a sniffare.
La mia protezione non è utilizzare un algoritmo sconosciuto, quanto
piuttosto una chiave irreversibile.
Matteo

 criptato con chiave irreversibile. E mi sembra di aver capito che se
]zac[
Non è esattamente cosi, se ricordo bene e in maniera piuttosto grezza, ssh
usa la chiave asimmetrica (non reversibile) per autentificarsi e per
scambiarsi una chiave simmetrica (piuttosto grande e molto variabile nel
tempo/connessione/ecc.), per poi usare la chiave simmetrica (reversibile)
per criptare il resto dei dati.
In nessun momento e in nessuna condizione è sniffabile in una qualsiasi
forma la chiave simmetrica, c'è solo il traffico di dati criptato che può
essere sniffato.
E' una condizione ben diversa e nettamente più sicura dal criptare un
singolo e breve testo con una chiave simmetrica e immutabile per molto
tempo.
Tanto per fare qualche numero il tuo sistema sarebbe almeno 1000 (che mi
piaccia esagerare?) volte più insicuro.

 piaccia esagerare?) volte più insicuro.
Non esageri, è sicuramente 10.000 volte più insicura.
In tutto questo discorso io escludo il brute force (su quello non può niente
nemmeno openssh con chiave a 1000000 di bit, perchè la teoria dice che
avendo un pc sufficentemente potente qualsiasi dato criptato anche con
chiave irreversibile può essere decriptato). Ovviamente escludo anche il
fattore fortuna
Matteo

Ecco l'algoritmo che ho intenzione di utilizzare
# echo $PASSWORD | openssl enc -e -a -k $CHIAVE
cGlwcG8K
in questo caso ho scelto come $CHIAVE l'md5sum di un file vuoto, ovvero:
CHIAVE="d41d8cd98f00b204e9800998ecf8427e"
decriptando viene:
# echo cGlwcG8K|openssl enc -d -a -k $CHIAVE
pippo
E 'pippo' è la password che avevo scelto.
Matteo

 In questo frangente di tempo, la chiave può essere sniffata.
]zac[
Non ho capito cosi intendi, comunque mi risulta che la chiave simmetrica
viaggi solo criptata dalla chiave asimmetrica (non reversibile).

 # echo cGlwcG8K|openssl enc -d -a -k $CHIAVE
]zac[
Quindi sposti la sicurezza dalla password alla chiave, quindi tutto dipende
da dove è posta la chiave, da chi è leggibile, come viene trasmessa dal
mittente al destinatario.
Supponendo che venga 'trasmessa' manualmente dall'amministratore sia al
mittente sia al destinatario e che non sia posta in nessuna zona 
accessibile agli utenti normali e/o a qualsiasi servizio, la sicurezza
dovrebbe essere discreta.
Mi rimane il dubbio che la sicurezza, dovuto al fatto che dipende unicamente
da una singola 'cosa', alla fine sia simile a un qualsiasi altro sistema
meno complesso (uso diretto della chiave o della password).
Forse ti sarebbe utile dare un'occhiata alla documentazione di kerberos e
sul modo in cui scambiano le informazioni.

 viaggi solo criptata dalla chiave asimmetrica (non reversibile).
In qualche modo dovrà pur essere messa in know_hosts; se viaggia in chiave
asimmetrica il client non saprebbe trovare cosa metterci. E in know_hosts
c'è la stessa riga che si trova in /etc/ssh/ssh_host_dsa_key. (credo)
Matteo

 
La posizione della chiave è legata all'hardware della macchina, non
memorizzata in nessun file, quindi la ritengo abbastanza sicura e l'unico
modo per generarla è essere root.
Tu mi dici però (ed effettivamente mi era venuto anche a me il pensiero),
che se utilizzo dentro uno script che ha 700
# mysql -u mysql -p ${passworddecriptata)
o utilizzare
# mysql -u mysql -p ${passwordinchiaro}
la sicurezza non dovrebbe variare di molto. Ho capito così?
Tutto questo mi viene perchè devo fare un backup di mysql, ed ho quindi
bisogno di autenticarmi. Sai se esiste un modo di backuppare mysql senza
loggarsi, essendo io root?
Matteo

 In qualche modo dovrà pur essere messa in know_hosts; se viaggia in chiave
]zac[
Con larga imprecisione:
Sul server è stata creata e inserita manualmente la chiave privata, sul
client è inserita manualmente la chiave pubblica (creata insieme alla
chiave privata).
Il client si connette al server, il server spedisce la chiave simmetrica
criptata con la chiave privata, il client decodifica la chiave simmetrica
con la chiave pubblica, in sintesi le stesse ''chiavi simmetriche'' usate
per autentificarsi sono utili per scambiarsi la chiave simmetrica.
La chiave simmetrica non è mai stata scambiata in una qualsiasi forma
umanamente e in tempi ragionevoli craccabile.

 bisogno di autenticarmi. Sai se esiste un modo di backuppare mysql senza
]zac[
Dovrebbe bastare che l'utente (normale) che usa il comando mysqldump (non mi
ricordo il nome esatto) abbia i permessi (gestiti da mysql) di accesso alle
tabelle di cui vuoi fare il backup, e dovrebbe essere facilmente possibile
tenere le parti 'sensibili' in una tabella a parte o in un database a
parte.

 
Non conoscendo a sufficienza il protocollo ssh credo che non sia molto
fruttuoso continuare questo ramo del 3ad.
Matteo

 database a parte.
Il problema č che io devo fare il backup dell'intero db.
Avevo pensato anche io a un utente chiamato 'backup' che entri in sola
lettura nel db. Il problema, come dici tu, sono le parti sensibili; le
parti sensibili sono solitamente le piů importanti da backuppare, e quindi
tale utente 'backup'dovrebbe avere i permessi anche su questo.
Ho bisogno del backup dell'intero db in vista di eventuali disaster recover.
Matteo