Hallo Forengemeinde, ich wollte Fragen ob ein Container der mit Truecrypt erstellt wird bei ordnungsgemäßer Handhabung unlesbar werden kann. Spezielle Anwendung: Server mit 5 1GB Festplatten ist zu einem RAID 6 System verbunden. Das Dateisystem ist sehr wahrscheinlich EXT4. Wenn das relevant ist könnte ich noch einmal nachschauen. Wenn auf diesem System ein beliebig großer Container erstellt wird. Kann es dann vorkommen, dass dieser Container nach einer bestimmen Zeit durch einen Soft- oder Hardwarefehler unlesbar wird? Habe Online von mehreren Quellen erfahren, dass ein Zerstören des Headers dazu führt, dass der gesamte Container unlesbar wird. Hier ist scheinbar der eigendliche Codierungsschlüssel hinterlegt. Aber warum sollte dieser zerstört werden? Währe Dankbar wenn mir jemand weiterhelfen könnte.
A. R. schrieb: > Kann > es dann vorkommen, dass dieser Container nach einer bestimmen Zeit durch > einen Soft- oder Hardwarefehler unlesbar wird? durch hardware fehler kann alles mögliche passieren. Es reicht schon wenn du keine ECC speicher verwendest und ein Defektes Modul hast. 4TB Daten mit Truecrypt zu verschlüsseln halte ich für sehr Riskant, wenn wirklich mal daten gerettet werden müssen hat man dort gar keine möglichkeit mehr. Da das ganze vermutlich nicht in einen Notebook eingesetzt werden soll, ist es vermutlich besser den Server sicher wegzuschließen. Im Betrieb hilft die verschlüsselung eh nichts weil sonst keiner zugreifen kann.
Ja, sowas kann passieren. Eben durch Software- oder Hardwarefehler, oder ganz einfach durch zufällige Einflüsse wie Strahlung. Genügt ja schon, wenn sich ein Bit falsch umdreht. Deshalb solltest du den Header auch extra sichern (und natürlich auch von den Volumes selbst oder den darin enthaltenen Daten regelmäßig Backups machen).
Vorneweg: Solange der Header intakt bleibt, geht der TC Container eigentlich nicht kaputt. Dass der Header kaputt geht ist mir leider auch schon zweimal passiert, hauptsächlich kann das bei Festplatten durch defekte Sektoren bzw. bei Flashspeichern durch kaputte Zellen passieren. Vorbeugen kann man dem, indem man die Header seperat abspeichert (evtl. in einem eigenen TC Container). Da du aber ein RAID 6 (RAID 5+1 nehme ich an) hast, kann ich mir kaum vorstellen, dass sich etwas an der Integrität deiner Daten ändert. Sollten deine Daten auf einer Festplatte beschädigt sein, sind sie ja durch das RAID mehrfach vorhanden. Wenn sich allerdings der RAID Controller verabschiedet kann es ein böses erwachen geben. Von Fehlern ohne Hardware-Einfluss hab ich allerdings noch nichts gehört. Bei mir laufen drei komplett verschlüsselte Festplatten seit 5 Jahren fehlerfrei ( und das ohne Parität). Grüße, Christian
Moin Moin, ja es ist möglich. Bei uns breits vorgekommen. Bei einem HDD kam es zu sporadischen Ausfällen. Grund war ein Wackelkontakt duch ein veraltetes Kabel. Blöde Sache. Nach dem dritten Ausfall in kurzes Zeit, waren die Daten nicht mehr lesbar. Container und Festplatte wurden vom System noch erkannt. Mussten einen Forensiker/Spezialisten konsultieren. Diagnose, Container und teilen der Hardware waren defekt. Ein Container kann kaputt gehen. Ich stelle mir die Frag, was ist wenn ein Container offen ist und dann die eigentliche Festplatte aus dem System genommen wird? Ist bei Windows ja möglich. Ob das System und TrueCrypt das abfangen können. Bezweifel ich. Aber das ist ein Extremfall. Im normelen Betrieb dürften solche Fehler nicht auftreten. Gruß
Marco ... schrieb: > > Ein Container kann kaputt gehen. Ich stelle mir die Frag, was ist wenn > ein Container offen ist und dann die eigentliche Festplatte aus dem > System genommen wird? Solange nicht genau in diesem Moment ein kritischer Schreibzugriff erfolgt, passiert gar nix. Du kannst das mit einem USB-Stick leicht nachvollziehen.
Server würde ich ebenfalls auf jeden Fall unverschlüsselt lassen und sie in einem sicher verschliessbaren Raum unterbringen. Anders sieht es aus, wenn Du mit illegalen Daten arbeitest, dann drängt sich eine Verschlüsselung schon auf. Das Gericht kann die illegalen Daten dann im besten Fall auf der beschlagnahmten Hardware nicht nachweisen und hat keine Beweise. Auf mobilen Geräten mit sensiblen Firmendaten ist eine Verschlüsselung auch zu empfehlen, da muss man dann halt regelmässig und häufig ein Backup erstellen.
Nu ich auch noch... Ich halte ein Raid für einen Server schon für sinnvoll, doch bitte unverschlüsselt. Für eine Datensicherung ein Raid zu nehmen halte ich aber für Unsinn. Fällt eine Platte aus kann es schwer werden (außer bei R1 vielleicht) Ich arbeite hier in meinen Büros seit Jahren mit TC und hatte noch nie ein Problem. Datensicherung auf ext. Platte auch verschlüsselt und doppelt. Bei den heutigen Plattenpreisen eigentlich kein Problem (ok, im Moment eher doch) Old-Papa
Deine Frage ist hinfällig, da ein RAID ein Backup nicht ersetzt. Du wirst also nach wie vor Backups machen wollen. Ansonsten unterscheidet sich das Risiko von Datenverlust nicht sonderlich von einem unverschlüsseltem System, Sicherung des Headers vorausgesetzt. Johnny B. schrieb: > Server würde ich ebenfalls auf jeden Fall unverschlüsselt lassen und sie > in einem sicher verschliessbaren Raum unterbringen. > Anders sieht es aus, wenn Du mit illegalen Daten arbeitest, dann drängt > sich eine Verschlüsselung schon auf. Das Gericht kann die illegalen > Daten dann im besten Fall auf der beschlagnahmten Hardware nicht > nachweisen und hat keine Beweise. Leider ist "illegal" heute nicht mehr ganz so klar definiert.
Vielen Dank für die vielen Antworten. Also Hardwarefehler kann wohl immer zu einem Datenverlust führen. Es ist jedoch eine wichtige Information zu wissen, ob bei einem Fehler alle oder nur die betroffenen Daten weg sind. Bei Truecrypt wird das kritisch, da alle Daten vom Betriebssystem nur noch als eine einzige Datei gesehen werden. So wie ich den Kommentar von Christian D. verstanden habe geht der gesamte Container nur dann kaputt, wenn der Header zerstört wird. Wie kann ich mir das vorstellen? Liegt der Header auf der Festplatte am Anfang von dem Container? Der Header enthält scheinbar den Schlüssel. Also ist klar wenn der Schlüssel beschädigt ist lässt sich die Datei nicht decodieren aber irgendwo müssen auch Daten sein, die dem Betriebssystem mitteilen, wie groß die Datei ist und wo diese anfängt. Wenn dieser Teil kaputt geht ist dann der Container verloren obwohl ich den Header gesichert habe? >Im Betrieb hilft die verschlüsselung eh nichts weil >sonst keiner zugreifen kann. Wiso? Ich kann doch normal über Truecrypt auf die Daten zugreifen und mit ner Hardware AES sollte das die Performance auch nur bedingt ausbremsen. >Von Fehlern ohne Hardware-Einfluss hab ich allerdings noch nichts >gehört. >Bei mir laufen drei komplett verschlüsselte Festplatten seit 5 Jahren >fehlerfrei ( und das ohne Parität). Das ist schoneinmal eine gute Information. >Ich halte ein Raid für einen Server schon für sinnvoll, doch bitte >unverschlüsselt. Für eine Datensicherung ein Raid zu nehmen halte ich >aber für Unsinn. Fällt eine Platte aus kann es schwer werden (außer bei >R1 vielleicht) Könntest du bitte erläutern warum der Defekt einer Platte zum Problem werden kann? >Deine Frage ist hinfällig, da ein RAID ein Backup nicht ersetzt. Du >wirst also nach wie vor Backups machen wollen. Das stimmt leider, jedoch reduziert ein RAID die Fehlerwahrscheinlich erheblich. Für sehr wichtige Daten werde ich aber in Zukunft wahrscheinlich noch ein Backup anlegen.
gaast schrieb: > Deine Frage ist hinfällig, da ein RAID ein Backup nicht ersetzt. Du > wirst also nach wie vor Backups machen wollen. Ansonsten unterscheidet > sich das Risiko von Datenverlust nicht sonderlich von einem > unverschlüsseltem System, Sicherung des Headers vorausgesetzt. Genau, RAID schützt bei Hardwareausfall und ein Backup gegen Datenverlust, welche durch einen Benutzer oder Programm verursacht wurden. Beides zusammen ist für wichtige Daten sinnvoll. > Johnny B. schrieb: >> Server würde ich ebenfalls auf jeden Fall unverschlüsselt lassen und sie >> in einem sicher verschliessbaren Raum unterbringen. >> Anders sieht es aus, wenn Du mit illegalen Daten arbeitest, dann drängt >> sich eine Verschlüsselung schon auf. Das Gericht kann die illegalen >> Daten dann im besten Fall auf der beschlagnahmten Hardware nicht >> nachweisen und hat keine Beweise. > > Leider ist "illegal" heute nicht mehr ganz so klar definiert. Ich denke es ist in den meisten Bereichen schon klar definiert, was verboten/illegal ist und was nicht. Bei uns z.B. gewisses rechtsextremes Gedankengut, harte P0rnografie, etc. Im Ausland wie z.B. China sind schon gewisse politische Ansichten illegal. Generell ist sicherlich zu fordern, nur legalen Aktivitäten nachzugehen. Trotzdem kann es unter gewissen Umständen trotzdem Gründe dagegen geben und für solche Fälle wäre dann schon eine Verschlüsselung zu empfehlen um sich zu schützen.
Johnny B. schrieb: > Im Ausland wie z.B. China sind schon gewisse politische Ansichten > illegal. Nicht nur dort. Auch im zivilisierten Mitteleuropa kann Engagement für Freiheit im Netz ganz schnell in Wiederbetätigungsvorwürfen enden. Auch das Zugangserschwerungsgesetz wäre wohl nicht so wie offiziell kommuniziert genutzt worden. Johnny B. schrieb: > Generell ist sicherlich zu fordern, nur legalen Aktivitäten nachzugehen. > Trotzdem kann es unter gewissen Umständen trotzdem Gründe dagegen geben > und für solche Fälle wäre dann schon eine Verschlüsselung zu empfehlen > um sich zu schützen. Leider ist heute prinzipiell davon auszugehen, dass man sich nicht im legalen Bereich bewegt.
A. R. schrieb: > So wie ich den Kommentar von Christian D. verstanden habe geht der > gesamte Container nur dann kaputt, wenn der Header zerstört wird. Wie > kann ich mir das vorstellen? Liegt der Header auf der Festplatte am > Anfang von dem Container? Bei Truecrypt, ja. Zusätzlich wird der Header an das Ende des Containers/Volumes "kopiert" http://www.truecrypt.org/docs/?s=volume-format-specification > Der Header enthält scheinbar den Schlüssel. Also ist klar wenn der > Schlüssel beschädigt ist lässt sich die Datei nicht decodieren aber > irgendwo müssen auch Daten sein, die dem Betriebssystem mitteilen, wie > groß die Datei ist und wo diese anfängt. Wenn dieser Teil kaputt geht > ist dann der Container verloren obwohl ich den Header gesichert habe? Solange nicht noch mehr beschädigt ist, sollte man den Container mit den üblichen Recovery-Tools wiederherstellen können. > Könntest du bitte erläutern warum der Defekt einer Platte zum Problem > werden kann? RAID 5, sollte man bei den heute nicht verwenden, u.a. da im Falle eines Ausfalls eines Laufwerks, die Daten mit relativ hoher Wahrscheinlichkeit nicht mehr rekonstruiert werden können. http://www.amplidata.com/pdf/The-RAID-Catastrophe.pdf
Ich hatte Truecrypt mal in einem Serverumfeld mit mehreren Clients ausprobiert. Und war erstaunt gewesen, dass es mehreren Clients problemlos möglich gewesen war, gleichzeitig auf den Container zuzugreifen. Offenbar fand kein Locking statt. Und damit war es für Einsatz auf einem Fileserver/NAS gestorben, denn so schiesst man das Filesystem im Container in Nullkommanix ab. Die üblichen Filesysteme sind nicht dafür konstruiert, gleichzeitig mehrfach gemountet zu werden.
@Arc Net, vielen Dank das sind sehr interessante Lektüren. Hatte im Moment leider nur Zeit den ersten Teil von dem pdf zu lesen. Ich verwende jedoch ein RAID 6 System und kein RAID 5 was die Sache etwas entschärfen sollte. Folgende Punkte wurden angesprochen: - Extrem lange Zeit zum Wiederherstellen nach dem Ausfall einer Festplatte. - Vorallen wenn die Wiederherstellen im Hintergrund geschieht um die Performance zu erhöhen. - Wahrscheinlichkeit ist hoch, dass mehrere Festplatten kurz hintereinander Ausfallen, weil meist selbes Alter und selbe Belastung. - Es kann zu einem "unrecovered read error" kommen. Die Punkte waren zum Teil bekannt. -Die Extrem langen Zeiten zum Wiederherstellen lassen sich leider nicht vermeiden. Das ist Heute ein echtes Problem. -Der Server wird von mir privat betrieben. Es handelt sich um ein QNAP TS-509. Deswegen kann ich mit einer Performanceeinbuße leben. -Um die Wahrscheinlichkeit eines gleichzeitigen Ausfall von mehreren Festplatten zu verringern wurden die 5 verwendeten Festplatten in 2 Paketen gekauft. Einmal 3 Stück zu einem späteren Zeitpunkt dann noch 2 Stück. -Was es genau mit einem "unrecovered read error" auf sich hat konnte ich noch nicht herrausfinden. Hierbei wird es auch Problematisch, dass ich nicht den genauen Rekonstruktionsalgorithmus kenne und somit nicht weiß wie das System auf falsche Bits reagiert. Also wird dann der gesammte Rekonstruktionsvorgang abgebrochen oder kommt es nur zu einem Bitfehler? Ersteres währe natürlich Fatal. >Und damit war es für Einsatz auf einem Fileserver/NAS gestorben, denn so >schiesst man das Filesystem im Container in Nullkommanix ab. Die >üblichen Filesysteme sind nicht dafür konstruiert, gleichzeitig mehrfach >gemountet zu werden. Das scheint ein sehr wichtiger Punkt zu sein. Jedoch kann ich momentan noch nicht abschätzen in wie weit das stimmt, da mir hier etwas das Wissen fehlt. Das soll nicht heißen, dass ich dir Misstraue. Werde versuchen etwas mehr in Erfahrung zu bringen.
A. R. schrieb: >>Und damit war es für Einsatz auf einem Fileserver/NAS gestorben, denn so >>schiesst man das Filesystem im Container in Nullkommanix ab. Die >>üblichen Filesysteme sind nicht dafür konstruiert, gleichzeitig mehrfach >>gemountet zu werden. > > Das scheint ein sehr wichtiger Punkt zu sein. Jedoch kann ich momentan > noch nicht abschätzen in wie weit das stimmt, da mir hier etwas das > Wissen fehlt. Das soll nicht heißen, dass ich dir Misstraue. Werde > versuchen etwas mehr in Erfahrung zu bringen. eigentlich ist das unwichtig, wenn man den container nicht "freigibt" sondern nur das laufwerk in den Container. Dann können auch nicht 2 leute gleichzeitig auf den container zugreifen. auf den Daten in den Container können mehrer gleichzeitg zugreifen.
Peter II schrieb: > eigentlich ist das unwichtig, wenn man den container nicht "freigibt" > sondern nur das laufwerk in den Container. Dann können auch nicht 2 > leute gleichzeitig auf den container zugreifen. auf den Daten in den > Container können mehrer gleichzeitg zugreifen. wer's nachlesen möchte http://www.truecrypt.org/docs/?s=sharing-over-network A. R. schrieb: > -Was es genau mit einem "unrecovered read error" auf sich hat konnte ich > noch nicht herrausfinden. Hierbei wird es auch Problematisch, dass ich > nicht den genauen Rekonstruktionsalgorithmus kenne und somit nicht weiß > wie das System auf falsche Bits reagiert. Also wird dann der gesammte > Rekonstruktionsvorgang abgebrochen oder kommt es nur zu einem Bitfehler? > Ersteres währe natürlich Fatal. URE oder NRE sind genau das, Fehler die nicht mehr vom Laufwerk korrigiert werden können. Bei RAID5 ist der Fehler fatal, bei RAID6 durch die doppelte Parität korrigierbar. Wenn nicht die relativ hohe URE von günstigen Laufwerke (Desktop-Teile 1/10^14 Bits, geeignetere 10^-15 bis 10^-16) zum Problem wird...
> Habe Online von mehreren Quellen erfahren, dass ein Zerstören des > Headers dazu führt, dass der gesamte Container unlesbar wird. Kann ich bestätigen. > Hier ist scheinbar der eigendliche Codierungsschlüssel hinterlegt. > Aber warum sollte dieser zerstört werden? Keine Ahnung.
A. K. schrieb: > Die üblichen Filesysteme sind nicht dafür konstruiert, gleichzeitig > mehrfach gemountet zu werden. Werden die denn mehrfach gemountet? Kann ich mir nicht vorstellen. Die CPU in der NAS-Kiste mountet als einzige das Filesystem und ist fürs Locking zuständig. Die an das NAS angeschlossenen Rechner haben mit dem physikalischen Dateisystem auf der NAS-Platte direkt nichts zu tun. Leistungsfähige NAS-Geräte benutzen ein Cache, wie jedes einigermaßen hochentwickelte OS auch.
Uhu Uhuhu schrieb: > Werden die denn mehrfach gemountet? Das Szenario war ein Server, der den Container als aus seiner Sicht normales File hostet, ihn aber nicht selbst entschlüsselt, sondern dies den Clients überlässt. In diesem Fall mountet jeder Client für sich und Clients ohne passendem Schlüssel können nichts damitanfangen. Wenn man den Server den Container entschlüsseln lässt und der die darin enthaltenden Files statt des Containers im Netz anbietet, dann ändert sich die Situation natürlich. Aber dann kommt jeder Client mit genug Zugriffsrecht auch dran. Ebendies widersprach der Ausgabenstellung.
A. K. schrieb: > Aber dann kommt jeder Client mit genug > Zugriffsrecht auch dran. Ebendies widersprach der Ausgabenstellung. wo steht da? Und ob ich nun einen client die Rechte gebe oder das Password ändert daran wenig. jetzt könnte man nur noch sagen der die Daten unverschlüsselt übertragen werden, aber dafür kann man einfach ipsec aktivieren.
A. K. schrieb: > Aber dann kommt jeder Client mit genug > Zugriffsrecht auch dran. Ich meine mal gehört zu haben, dass es neben Festplattenverschlüsselung auch noch andere Sicherheitsmechanismen gibt, mit denen sich z.B. Zugriffsrechte durchsetzen lassen.
Peter II schrieb: > Und ob ich nun einen client die Rechte gebe oder das Password ändert > daran wenig. Ausser wenn du erreichen willst, dass justament jener Admin, der die Rechte vergibt, da nicht reingucken können soll. Denn das Containerpasswort muss der weder kennen noch ändern können.
Der dicke Holger schrieb: > Ich meine mal gehört zu haben, dass es neben Festplattenverschlüsselung > auch noch andere Sicherheitsmechanismen gibt, mit denen sich z.B. > Zugriffsrechte durchsetzen lassen. Die setzen allerdings voraus, daß Unbefugte niemals physischen Zugriff auf den Server bzw. die Platten erlangen können. Verschlüsselung dient NICHT der Regelung von Zugriffsrechten im Netzwerk. Sie soll lediglich verhindern, daß die Daten ausgelesen werden, ohne daß der Zugreifende über den Schlüssel verfügt.
Stimmt schon, ich finde es nur nicht richtig die Schuld einer Software zu geben die für diesen Einsatzzweck gar nicht primär gedacht ist. Wie soll denn auch die Datenkosistenz sichergestellt werden wenn der Server die Daten nicht entschlüsseln kann und somit allenfalls sagen kann ob sich die Daten in irgendeiner Weise verändert haben. An und für sich müssten bei dem beschriebenen Szenario alle Clients ständig untereinander abgleichen ob irgendwelche Änderungen gemacht wurden. Das dies das Primärziel von TrueCrypt ist wage ich aber zu bezweifeln. Eher geeignet wäre hier wohl eine Art Subversion welches lokale Änderungen mit den entschlüsselten Serverdaten abgleicht und im Falle von Änderungen diese entweder lokal übernimmt oder aber verschlüsselt an den Server sendet.
auch stellt sich die Frage der Datensicherung, wenn der Server selber keinen zugriff auf den inhalt hat. dann müsste er immer Diese 4TB sichern. Ich kann ja überhaupt nicht erkennen ob und was sich geändert hat.
Der dicke Holger schrieb: > Eher geeignet wäre hier wohl eine Art Subversion welches lokale > Änderungen mit den entschlüsselten Serverdaten abgleicht und im Falle > von Änderungen diese entweder lokal übernimmt oder aber verschlüsselt an > den Server sendet. Das würde ähnliche Mechanismen erfordern wie in Datenbanken. Auf Dateisystemebene kaum machbar. Peter II schrieb: > dann müsste er immer Diese 4TB sichern. Ja, muß er. Zudem lassen sich Truecrypt-Container auch noch schlecht komprimieren.
> Ja, muß er. Zudem lassen sich Truecrypt-Container auch noch schlecht > komprimieren. Viren, HD-Softfehler und tückische RAM-Fehler usw. sind bei verschlüsselten Daten auch kaum zu ermitteln. Summasumarum es wird nicht sicherer nur komplizierter. 5x 1GB Festplatten zu einem RAID 6 ohne Backup entspricht einer klapprigen Weihnachtaumbeleuchtung mit lockerer Kerze.
oszi40 schrieb: > Viren, HD-Softfehler und tückische RAM-Fehler usw. sind bei > verschlüsselten Daten auch kaum zu ermitteln. Kannst du dies näher erläutern?
Wenn ich nen komplett Backup von nem Truecrypt Container mache (=die Container Datei auf andere Platte kopieren), danach dann im original Container neue Daten hinzufüge oder ändere, schwächt das dann die Stärke der Verschlüsselung wenn man zugriff auf beide Versionen der Datei hat? Weil dann könnte man ja anhand der differenz der beiden Dateien evtl. auf irgendwas rückschließen? Ich hab keine Ahnung von Verschlüsselung - ist nur so eine Idee die mir gerade gekommen ist ;-)
Der dicke Holger schrieb: > Stimmt schon, ich finde es nur nicht richtig die Schuld einer Software > zu geben die für diesen Einsatzzweck gar nicht primär gedacht ist. Schuld? Nein, ich finde es nur etwas gefährlich, dass die Software - oder die bestimmte Version - kein Locking durchführt. > Eher geeignet wäre hier wohl eine Art Subversion welches lokale > Änderungen mit den entschlüsselten Serverdaten abgleicht und im Falle > von Änderungen diese entweder lokal übernimmt oder aber verschlüsselt an > den Server sendet. Viel zu kompliziert gedacht. Ich hatte lediglich erwartet, dass das Container-File gelockt wird solange es offen ist und daher niemand sonst währenddessen darauf zugreifen kann.
A. K. schrieb: > Das Szenario war ein Server, der den Container als aus seiner Sicht > normales File hostet, ihn aber nicht selbst entschlüsselt, sondern dies > den Clients überlässt. In diesem Fall mountet jeder Client für sich und > Clients ohne passendem Schlüssel können nichts damitanfangen. OK, dann kann das nur gehen, wenn Truecrypt im Container Locktabellen führt und die auch noch multiuserfähig bedint. Das dürfte allerdings die Performance in den Keller drücken. Ohne eine Instanz auf dem Server kann das kaum was werden. Die sichere Verbindung zum LAN-Client könnte man dan mit webDav über https hinbekommen. Hohe Sicherheit kostet eben einen hohen Preis...
Uhu Uhuhu schrieb: > OK, dann kann das nur gehen, wenn Truecrypt im Container Locktabellen > führt und die auch noch multiuserfähig bedint. Das dürfte allerdings die > Performance in den Keller drücken. nein, man kann eine Datei (den containt) einfach exclusiv öffnen.
Peter II schrieb: > nein, man kann eine Datei (den containt) einfach exclusiv öffnen. Dann ist die Chose aber auch nicht multiuserfähig...
Uhu Uhuhu schrieb: > Dann ist die Chose aber auch nicht multiuserfähig... Nacheinander schon. ;-) Nein, das hatte ich auch nicht ernsthaft erwartet. Es ist einfach nur ein deutliches Risiko, sich versehentlich den Inhalt zu himmeln.
vn nn schrieb: > oszi40 schrieb: >> Viren, HD-Softfehler und tückische RAM-Fehler usw. sind bei >> verschlüsselten Daten auch kaum zu ermitteln. > > Kannst du dies näher erläutern? 1.Hast Du schon mal mit einer Avira-Rettungs-CD eine gut verschlüsselte Datei öffen/ innen durchsuchen können?? Ich nicht. 2.Leichte Softfehler auf HDs werden oft durch die HD-Fehlerkorrektur und Filesystem ausgebügelt, ohne daß der User etwas merkt. Ob dann bei Deinen Giga-Daten ein Zeichen falsch war, ist schwer zu prüfen (kommt aber in seltenen Fällen vor). Die SMART-Werte sind ein kleiner Hinweis zur HD-Gesundheit. Sie sagen aber nix darüber aus, ob z.B. Deine spätere verschlüsselte Kaffeeliste.xls dadurch in der "Spalte a17" heute einen Folgefehler hat. SMART:http://de.wikipedia.org/wiki/Self- Monitoring,_Analysis_and_Reporting_Technology 3.Speicherfehler auf dem Adapter sind tückisch, weil man sie nur durch Hardwaretausch bemerkt oder löst. Das Fehlerbild war selten offensichtlich. Erfreulicherweise ein seltener Fehler bisher.
oszi40 schrieb: > 1.Hast Du schon mal mit einer Avira-Rettungs-CD eine gut verschlüsselte > Datei öffen/ innen durchsuchen können?? Ich nicht. War auch noch nie nötig. Wenn man aufgrund offenbar vorhandener Sicherheitsmängel tatsächlich auf Virenscanner angewiesen sein sollte, kann man ja den Container vorher mounten. oszi40 schrieb: > 2.Leichte Softfehler auf HDs werden oft durch die HD-Fehlerkorrektur und > [...] > Folgefehler hat. SMART:http://de.wikipedia.org/wiki/Self- > Monitoring,_Analysis_and_Reporting_Technology Den Zusammenhang mit der Verschlüsselung hast du damit nicht erläutert. Die Fehlerkorrektur arbeitet logischerweise unabhängig von der Art der Daten, ob es nun ein Textfile oder ein Binärformat ist, ist recht egal. oszi40 schrieb: > 3.Speicherfehler auf dem Adapter sind tückisch, weil man sie nur durch > Hardwaretausch bemerkt oder löst. Das Fehlerbild war selten > offensichtlich. Erfreulicherweise ein seltener Fehler bisher. Ja, aber warum genau sollen Fehler nun bei einer Verschlüsselung schwerer ermittelt werden können?
vn nn schrieb: > Die Fehlerkorrektur arbeitet logischerweise unabhängig von der Art der > Daten, ob es nun ein Textfile oder ein Binärformat ist, ist recht egal. Nur zum Vergleich: Wenn von 100 Textdateien.txt eine kaputt sein sollte, kannst Du mit etwas Glück noch 99 lesen. Wenn Du z.B. 100 Textdateien in ein großes zip komprimierst, wirst Du weniger Glück haben und lesen kannst Du das gezippte "mit bloßem Auge" auch nicht. Je größer eine Datei (Container) ist, desto höher ist die Wahrscheinlichkeit eines Fehlers.
A. R. schrieb: > Habe Online von mehreren Quellen erfahren, dass ein Zerstören des > Headers dazu führt, dass der gesamte Container unlesbar wird. Hier ist > scheinbar der eigendliche Codierungsschlüssel hinterlegt. Aber warum > sollte dieser zerstört werden? Der eigentliche Key mit den verschlüsselt wird liegt im Header des Containers. Das Secret was der User eingibt entschlüsselt den o.g. Key,
>Nur zum Vergleich: Wenn von 100 Textdateien.txt eine kaputt sein sollte, >kannst Du mit etwas Glück noch 99 lesen. Wenn Du z.B. 100 Textdateien in >ein großes zip komprimierst, wirst Du weniger Glück haben und lesen >kannst Du das gezippte "mit bloßem Auge" auch nicht. Einen TrueCrypt-Container kann man nicht mit einem komprimierten ZIP-File vergleichen - mal abgesehen von einer gewissen Ähnlichkeit bei einer statistischen Analyse der verschlüsselten Daten auf der einen und der komprimierten Daten auf der anderen Seite! Soweit ich weiß nutzt TrueCrypt den XTS-Modus. Hier dürfte eine Beschädigung von "Außen"(also mit Sicht auf die noch verschlüsselten Daten) stets mindestens einen der Blocklänge der Verschlüsselung entsprechenden Bereich beschädigen. Wenn Du z.B. 128 Bit AES fährst und von "Außen" im Container ein einzelnes Bit beschädigst, wird im inneren des Containers(also mit Sicht auf die bereits entschlüsselten Daten) ein der Blocklänge entsprechender zusammenhängender Bereich beschädigt. Bei 128 Bit Blocklänge würde ein einzelnes beschädigtes Bit demnach 16 aufeinander folgende Bytes innerhalb des Containers beschädigen. Mehr aber auch nicht. Sofern der Header nicht beschädigt ist und die Block-Länge kleiner als die Mindest-Länge einer einzelnen Datei ist, solltest Du auch bei einem noch so riesigen Container die Möglichkeit haben, die nicht beschädigten Dateien zu lesen. >Je größer eine Datei (Container) ist, desto höher ist die >Wahrscheinlichkeit eines Fehlers. Dem stimme ich zu, allerdings dürfte diese Aussage unabhängig von einer vorhandenen Verschlüsselung richtig sein. Mfg, HP
Johnny B. schrieb: > Genau, RAID schützt bei Hardwareausfall und ein Backup gegen > Datenverlust, welche durch einen Benutzer oder Programm verursacht > wurden. Das ist nicht der zentrale Punkt. RAID schützt bei einigen Arten von Hardware-Ausfällen nicht. > Beides zusammen ist für wichtige Daten sinnvoll. RAID ist primär nicht für höhere Datensicherheit, sondern lediglich für höhere Verfügbarkeit gedacht, also zum Minimieren der Downtime. > Ich denke es ist in den meisten Bereichen schon klar definiert, was > verboten/illegal ist und was nicht. Bei uns z.B. gewisses rechtsextremes > Gedankengut, harte P0rnografie, etc. > Im Ausland wie z.B. China sind schon gewisse politische Ansichten > illegal. Oder in Frankreich das Verschlüsseln von Festplatten. A. K. schrieb: > Ich hatte Truecrypt mal in einem Serverumfeld mit mehreren Clients > ausprobiert. Und war erstaunt gewesen, dass es mehreren Clients > problemlos möglich gewesen war, gleichzeitig auf den Container > zuzugreifen. Offenbar fand kein Locking statt. Warum erstaunt dich das? Das ist doch das gleiche, als ob du eine Partition "roh" an andere Rechner freigibst und die dann einfach auf allen gleichzeitig mountest. Das ist ja nun ziemlich weit weg von einem üblichen Anwendungsfall. Natürlich führt das zu Problemen. A. R. schrieb: > -Um die Wahrscheinlichkeit eines gleichzeitigen Ausfall von mehreren > Festplatten zu verringern wurden die 5 verwendeten Festplatten in 2 > Paketen gekauft. Einmal 3 Stück zu einem späteren Zeitpunkt dann noch 2 > Stück. Am besten sollten es noch Platten von verschiedenen Herstellern sein. So kann man z.B. einen Firmware-Bug ausschließen, der sonst auch mal auf mehreren Platten gleichzeitig Daten zerstören könnte. A. K. schrieb: > Wenn man den Server den Container entschlüsseln lässt und der die darin > enthaltenden Files statt des Containers im Netz anbietet, dann ändert > sich die Situation natürlich. Aber dann kommt jeder Client mit genug > Zugriffsrecht auch dran. Ebendies widersprach der Ausgabenstellung. Verstehe ich nicht. Die Zugriffsrechte sind doch genau dafür da, sowas zu steuern.
Rolf Magnus schrieb: > Warum erstaunt dich das? Das ist doch das gleiche, als ob du eine > Partition "roh" an andere Rechner freigibst und die dann einfach auf > allen gleichzeitig mountest. Wie schon beschrieben wurde erstaunte mich nur, dass der Container nicht exklusiv geöffnet wurde. Ja, das ist zwar bis auf das weniger simple exklusive Öffnen technisch einer mehrfach gemounteten Partition ähnlich, aber ein versehentlich mehrfach geöffneter Container ist sehr viel wahrscheinlicher, insbesondere weil einem Normalanwender dieses Risiko garantiert nicht bewusst ist. Aber welcher Normalanwender mountet schon selbst Partitionen? > Verstehe ich nicht. Die Zugriffsrechte sind doch genau dafür da, sowas > zu steuern. Wie schon beschrieben wurde kann ein Administrator sich ggf. selbst das Recht geben, darauf zuzugeben. Ihm nicht nur den Zugang zu den Daten sondern auch das Recht zu nehmen, Rechte zu ändern, behindert administrative Arbeitsprozesse. Ausserdem gibt es den Markt für Verschlüsselungsprodukte nicht nur deshalb, weil dumme Admins keine Ahnung von Rechtevergabe haben. Ein paar andere Gründe gibts auch noch - und die spielten hier auch eine Rolle. Ich hatte das auch nur erwähnt, weil fehlendes Locking auch schon bei einfacher privater Nutzung eines Containers auf einem Fileserver/NAS zu Problemen führen kann, wenn man den versehentlich mehrfach mountet. Wenn der Container lokal auf der Platte liegt ist das weniger wahrscheinlich,. Nur darum ging es mir in diesem Thread. Vielleicht ist das ja auch mittlerweile behoben, ich hatte das seither nicht mehr ausprobiert.
A. K. schrieb: > Wie schon beschrieben wurde erstaunte mich nur, dass der Container nicht > exklusiv geöffnet wurde. Hast du einen Bugreport geschrieben?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.