Beiträge von gehrke

    Die allermeisten erfolgreichen Angriffe beruhen auf der falschen Meinung, man habe genügend für die Sicherheit getan.
    Das ist immer falsch.


    Aber wenigstens ängstigt ihr euch mit diesem Irrglauben nicht so sehr.
    Is ja auch was wert.


    Entschuldige bitte meine Offenheit, aber diese Aussage ist - wie die zuvor von Dir getätigten eigentlich auch schon - eher weniger hilfreich. Nur Allgemeinplätze absondern und sich allgemein über die Ahnungslosigkeit der Leute lustig zu machen ist etwas schwach - und nicht gerechtfertigt in diesem Fall.

    Weil man nach der ersten verschlossenen Tür ein Schlüsselkästchen hängen hat für alle weiteren Puppenhaustresörchen?


    Das setzt aber voraus, dass unterschiedliche Sicherheitslevel angestrebt werden - das muss aber nicht zwingend der Fall sein.


    Mir persönlich reicht es zum Beispiel aus, wenn die Daten auf den weiteren Disks mit dem selben Level behandelt werden wie die auf der ersten. Und unter der Voraussetzung, dass gleiche LUKS-Parametrisierung gegeben ist, ist das IMHO auch bei der vorgestellten Lösung so gegeben.

    Wenn ich die erste verschlüsselte Partition eh schon durch manuelle Eingabe des Spasswortes einbinden muss,
    ist ein Keyfile lediglich eine Schwächung der Sicherheit.


    Das müsstest Du bitte näher erläutern - jedenfalls für mich.
    Da das keyfile innerhalb des verschlüsselten Containers liegt, sehe ich die zwingende Schwächung der Sicherheit noch nicht.


    Lasse ich alle Parititionen (mit oder OHNE boot) verschlüsselt via keyfile entsperren, habe ich ein Sicherheitssystem, dass dem Eindringling schon bei Annäherung auf 50m das Scheunentor komplett öffnet.


    Ja, aber davon hat ja auch keiner gesprochen. Es ging ja nicht darum, alle Parititionen per keyfile zu entsperren, sondern um alle ausser der initialen mit dem OS. Hierfür ist weiterhin die Passphrase beim Start erforderlich (falls ich den TE nicht falsch verstanden habe), und ohne die kommt auch der Angreifer nicht an den Rest.

    Das geht schon, wenn man Prioritäten setzt. Man MUß ja nicht alles beim Start mounten. Besonders sensibele Daten sollte man auf einer Partition oder Container speichern der nicht "autogemountet" wird.
    Ich selber habs halt so gemacht das ich meine verschlüsselte Partition NUR bei Bedarf mounte,


    Dein Ansatz kollidiert mit der Vorstellung von Sicherheit eines typischen 'mittleren Paranoikers'. ;)
    Hier ist die Überlegung dann, dass das OS schon - beispielsweise durch eine Offline-Attacke ('evil maid') - kompromittiert und eine sichere Verwaltung der Schlüssel nicht mehr gegeben sein könnte (Keylogger, Auslesen des Keys aus dem RAM). Oder das Vorhandensein von sicherheitsrelevanten oder vertraulichen Daten im SWAP. Oder, oder, oder...
    Da aber ein 'fast-vollständig verschlüsseltes System' mit LVM+LUKS anno 2015 bei vielen Distributionen (openSUSE, debian, RedHat) auch schon zum Bereich der Standard-Konfiguration gehören, sehe ich gar keinen Anlass, hier den Standard aufzuweichen. Bei mir jedenfalls funktioniert das seit Jahren prima ohne fühlbare Performance-Probleme.


    neben einem unverschlüsselten /boot ein LVM mit / und swap


    Bei der Konfiguration mit LUKS+LVM ist (mit Ausnahme von /boot) alles verschlüsselt, wodurch sich ein kleineres Angriffpotential bietet als bei Verwendung lediglich einer dedizierten verschlüsselten Partition für bestimmte Daten.


    Paranoiker weiterer fortgeschrittener Level bannen zusätzlich ihr Boot-Device aus Angst vor Bootkits auf einen USB-Stick und tragen den immer bei sich und/oder meiden UEFI-Boards aus dem selben Grund. Letzteres wird leider immer schwieriger.

    Also ich nutze diese Lösung, damit die zweite eingebaute Platte gleich beim Hochfahren entsperrt und gemountet wird

    Ist klar.

    und ich finde das sehr elegant.

    Ich würde mir eine Lösung wünschen, bei der die zusätzlichen Schlüssel selbst verschlüsselt in dem ersten LUKS-Container liegen und dann zum Zeitpunkt der Eingabe der Passphrase damit dieser Bereich einmalig entschlüsselt wird, um auf die zusätzlichen Keys zuzugreifen. Im weiteren Betrieb lägen diese Keys dann nicht unverschlüsselt auf der Platte.


    Eine solche Lösung für den fortgeschrittenen Paranoiker habe ich bislang noch nicht gefunden, zumindest nicht mit Support durch die jeweiligen Distributionen.

    Moin Rüdiger

    1. Ein Einbrecher, die Polizei oder Steuerfahndung kommt unangemeldet in meine Wohnung oder ein Hacker verschafft sich Zugriff auf mein System, währen ich vor dem PC sitze. Dann ist völlig egal, ob ich mit einer Passphrase die 2te Platte aufgeschlossen habe oder ob das via keyfile passiert ist.


    Aber das sind IMHO zwei Szenarien, die auch unterschiedlich bewertet werden solten.


    Im ersten Fall ist erstmal noch nichts verloren. Ohne Deine Mithilfe gibt das System erstmal noch keine Daten preis, wenn Du einen Screenlocker mit Password verwendest. Klar können die das System mitnehmen, aber dann ist auch die Stromversorgung unterbrochen oder es gelingt Dir noch rechtzeitig, den Stromstecker zu ziehen. Dann greift der Schutz von LUKS wieder. Und üblicherweise kommt die Steuerfahndung nicht gleich mit dem notwendigen Equipment für eine Kaltstart-Attacke.


    Im anderen Fall 'Hacker-Attacke online' sieht es prinzipiell ganz anders aus, dafür bietet LUKS wie Du schon richtigst sagst, keinerlei Schutz. Da müssen andere Verteidigungsmechanismen greifen.

    Ich habe diese recht einfache Lösung bei mir ebenfalls im Einsatz, allerdings nur mangels bessererer Alternativen. Ich bin damit nicht vollständig zufrieden, weil ich auch sehe, dass die zusätzlichen Keys nur sehr schwach geschützt sind, solange der umgebende LUKS-Container online/gemountet ist.


    Allerdings ist der Schutz dann gegeben, wenn der LUKS-Container offline ist, beispielsweise das System runtergefahren ist. Insofern sind für mich damit meine persönlichen Mindestanforderungen erfüllt. Aber schön geht anders...