[bartii]

Zitat (ph030: 21.10.2007, 08:17)

Das heist? Hast du dein Keyfile als .jpg oder ähnliches benannt, obwohl es keine entsprechende Datei ist? Das wäre nicht sehr intelligent, dann lieber ein richtiges Bild.

Ja

Zitat

Desweiteren solltest du natürlich System und Nutzdaten separat verschlüsselt haben und nur on-demand freigeben

Das stimmt.

Zumindest ist es sicher bei einem Diebstahl des Notebooks.

[ph030]

Zitat

Ja

Nicht toll, sollte einem das Medium in die Hand fallen, kann man ja schon locker mit einem Einzeiler überprüfen, ob die Datei enthält, was die Endung verspricht. Dann lieber ein richtiges Bild und wenn es einem nicht zuviel Aufwand ist, vielleicht noch per Steganographie etwas einbetten und auslesen lassen.

[bartii]

Zitat (ph030: 21.10.2007, 11:33)

Nicht toll, sollte einem das Medium in die Hand fallen, kann man ja schon locker mit einem Einzeiler überprüfen, ob die Datei enthält, was die Endung verspricht.

Ja das hab ich mir auch sofort gedacht, nachdem ich die Datei mit dem Editor geöffnet hatte (ungefähr nur eine Zeile voll).

Ich befasse mich mal mit deinem Vorschlag. Danke.

[bartii]

Zitat (bartii: 09.10.2007, 10:48)

Apropos Truecrypt. Die Systempartition kann ich nicht verschlüsseln, habe ich in der Doku gelesen, aber was ist eigentlich mit dem Benutzprofil (z.B9 unter Windows) -> muss das auch entschlüsselt bleiben?

Huch, mir ist gerade was in den Kopf geschossen. Warum erst jetzt.

Es sollte doch möglich sein mit Hilfe einens Bootmanagers: Grub? die Festplatte vor dem Bootvorgang zu entschlüsseln.
Somit könnte ich doch komplett alles verschlüsseln, außer die bootpartition (ca. 50MB).

Noch eine Frage dazu.
Wenn ich ein RAID-Controller habe- kommt Grub damit klar?

[ph030]

Zitat

Somit könnte ich doch komplett alles verschlüsseln, außer die bootpartition (ca. 50MB).

Dabei sollte dir aber bewußt sein, dass man dann immer noch die Daten auf der Bootpartition manipulieren und somit Passwörter oder Keyfiles abfangen könnte...wenn, dann solltest du das auf ein externes Medium auslagern, was du immer bei dir führen kannst(USB-Stick, Speicherkarte, ...) und dann davon booten.

[bartii]

Zitat (ph030: 13.11.2007, 11:05)

Dabei sollte dir aber bewußt sein, dass man dann immer noch die Daten auf der Bootpartition manipulieren und somit Passwörter oder Keyfiles abfangen könnte...wenn, dann solltest du das auf ein externes Medium auslagern, was du immer bei dir führen kannst(USB-Stick, Speicherkarte, ...) und dann davon booten.

Stimmt. Sprich also den Bootloader auf einen Speicherstick tuen.
Ich habe noch nicht weiter gelesen. Aber Truecrypt kommt dann auch auf den USB-Stickdder Bootmanager(Grub) startet es. Oder wie läuft es ab? Keyfiles sind meiner Meinung nach eher ein Risiko. Sollte jemanden der Stick in die Handfallen, wars das.

Dieser Beitrag wurde von bartii bearbeitet: 13. November 2007 - 11:11

[ph030]

Kann ich dir bei Windows und TrueCrypt nicht sagen, da ich das nie genutzt habe. In Sachen Linux bzw. BSD habe ich den Kernel - und was sonst so nötig ist, um booten zu können - auf einer SD-Karte, von der wird gebootet, die Platten entschlüsselt, dann via pivot_root zum eigentlichen System gewechselt und dort der Init-Prozess gestartet.

Ich hab mal was gelesen, dass das theoretisch auch mit Win+TC klappen würde - über Umwege - kann ich aber wie gesagt nicht persönlich bestätigen.

[bartii]

Danke.

Wenn ich das jetzt richtig verstanden habe, kann ich das ganze so realisieren:
Ich installiere LinuxX auf einer Speicherkarte - natürlich nur die Shell. Hinzukommt Truecrypt. Ich boote nun von der Karte und starte Truecrypt und die Platten zu entschlüsseln.

Dann muss zum eigentlichen Systemgewechselt werden.
Zum letzten Punkt muss ich noch ein wenig lesen, denke ich .

Das ganze sollte funktionieren.
Will ich das nun unter Win realisieren, wird es schwierig sein, dass BS zu wechseln, wie du bereits gesagt hast.

Schnellste Lösung wäre nun, eine Win-VM zu booten. Denn sollten die Probleme beseitigt sein Optimale Lösung ist dies natürlich nicht, aber ein Ansatz.

Dieser Beitrag wurde von bartii bearbeitet: 13. November 2007 - 11:24

[bartii]

Zitat (bartii: 13.11.2007, 11:21)

Schnellste Lösung wäre nun, eine Win-VM zu booten. Denn sollten die Probleme beseitigt sein Optimale Lösung ist dies natürlich nicht, aber ein Ansatz.

Aufgrund von Keyloggern etc fällt das ja eigentlich auch weg.

Kommt das eigentlich auch in dein Sicherheits-Tut?

[bartii]

Apropos Verschlüsselung.
Microsoft hat viele Firmenkunden. Nun Frage ich mich, warum die BitLocker nicht in der Business-Version anbieten.
Sei es drum, ob jemand es benutzen würde.

[bartii]

Gut, das andere war schon alt.

Mit dem 30 MB Ding ist die Partion gemeint, auf der der Bootloader installiert ist (Nicht MBR). BSP: Grub

Ich habe das eh jetzt anders gelöst: cryptsetup + LUKS

Die einzige Partition die unverschlüsselt ist, ist eben die wo der Bootloader drauf ist. Dieser greift auf virtuelle Laufwerke zu, um die anderen Partitionen zu entschlüsseln. Ich werde direkt nach dem Passwort gefragt.

Das mit dem Kelogger kannst du umgehen, in dem du Keys benutzt, die du auf einem verschlüsselten USB Stick hast (muss wiederum mit einem Passwort entschlüsselt werden) od. auf eine CD brennst.

Sicher können diese Keys auch gesichert werden.

Oder du machst es wie ph - du bootest von nem Stick/CD und rootest auf dein System um. Damit sollte es am sichersten sein.

Warum denn? Bitlocker sollte doch für Firmen nützlich sein, die Windows einsetzen. Stell dir mal vor, es werden Firmennotebooks oder PCs geklaut.

Dieser Beitrag wurde von bartii bearbeitet: 16. Januar 2008 - 11:39

[ph030]

Zitat

StartPartition, die bei dir 30 MByte ist (Häähhh)

Hat ja nicht jeder Windows, mit ein bisschen Gefriemel reichen ja auch schon 2Mb

@bartii, du lässt dann aber hoffentlich auch schön den Kernel und (so vorhanden) sonstiges Wichtiges auf /boot per Chksums prüfen, oder...sonst ergibt das ja keinen Sinn

BTW, die Idee mit der Umbenennung in Lc sagt mir immer mehr zu

Dieser Beitrag wurde von ph030 bearbeitet: 16. Januar 2008 - 11:43

[bartii]

buff nur schade, dass Linux drauf kackt.

Zitat (ph030: 16.01.2008, 11:42)

@bartii, du lässt dann aber hoffentlich auch schön den Kernel und (so vorhanden) sonstiges Wichtiges auf /boot per Chksums prüfen, oder...sonst ergibt das ja keinen Sinn

Oh, ob ich heute wieder etwas zu tun habe ?

[ph030]

Na, so schwer ist das ja nicht zu implementieren, einfach in das Init-Skript ein (z.B.)

sha512sum /boot/$kernel

einbauen und dann entweder optisch oder mit Daten auf einem - möglichst - schreibgeschützten Medium prüfen. Allerdings ist da der Kernel natürlich schon geladen und man erkennt nur, ob man sich noch trauen darf, etwas einzugeben - komplett von was externem booten wäre natürlich besser.