[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Verschlüsselten Server/Client mittels SSH-Client automatisch entsperren



Hallo Stefan,  Hallo Heiko,  Hallo Matthias,

Stefan Baur schrieb am Freitag, den 22.03.2019 um 15:56:
> Am 22.03.19 um 15:49 schrieb Heiko Schlittermann:
  Matthias Boden schrieb:
> >> Grundsätzlich funktioniert diese Prototyp schon ganz gut. Ich würde hier
> >> gerne Anregungen zu dem Verfahren und der Umsetzung sammeln. Besonders
> >> interessant ist die Updatefähigkeit unserer Lösung.
> > Und warum legst Du nicht gleich den Key für die Platte in die initramfs?
> > Ob das nun der SSH private Key ist (den Du vermutlich nicht mit einer
> > Passphrase schützt, denn wer sollte die beim Booten eingeben), oder der
> > Key für das Luks, was ist der Unterschied?
> 
> Na ja. $BEHOERDE oder $BOESER_BUBE kommt und nimmt den Server mit.
> Dann hat er auch den Key für die Platte, wenn der in der initramfs ist.
> 
> Wenn Du weißt/ahnst, dass der Server von jemandem entwendet wurde,
> kannst Du hoffen, dass derjenige den Server heruntergefahren hat und ihn
> nicht an einer USV hängend "entführt" hat. Beim Wiedereinschalten will
> er dann mit dem SSH-Server reden. D.h. erstens hast Du vielleicht eine
> trackbare IP, zweitens, wenn Du es mitbekommen hast, gibst Du in dem
> Moment den Platten-Key nicht mehr raus.
> 
> Ich halte das allerdings für nicht allzu realistisch, dass man auf die
> Art und Weise einen ernsthaften "Datendieb" abwehrt. Zumal es ja auch
> noch so Spielchen wie DMA-Attacken, Cold-Boot-Attacken, etc. gibt, um an
> Key oder gar die gesamten Daten zu kommen.

Eure Argumentation ist teilweise einleuchtend.  

Jedoch hatte Matthias Boden mit seiner Idee vielleicht Anwender
im Sinn, die ihre Festplatten nur deshalb verschlüsseln wollen,
weil das die datenschutzkonforme Entsorgung der Datenträger
später deutlich vereinfacht.  Es muss dann nur noch der zu
seinem "dropbear private key file" gehörende SSH-Key auf dem
Server gesperrt und/oder der zugehörige "key.txt" auf seinem
einen zentralen Server gelöscht werden, um den Zugang zu den
verschlüsselten Daten „fast unmöglich“ zu machen.

Insofern ist die Idee für Computer, die unbeaufsichtigt booten
können müssen, gar nicht so schlecht.  Jedenfalls besser,
als deren Daten überhaupt nicht zu verschlüsseln.

In der Implementierung auf github habe ich ein kleines Problem
gesehen: Es ist im Moment fest nur die Plattform x86_64
vorgesehen.  Getestet habe ich nichts.  Nur kurz einen Blick
in das github-Repository geworfen.

Liebe Grüße, Peter Funk
-- 
Peter Funk ✉:Oldenburger Str.86, D-27777 Ganderkesee; ☎:+49-179-640-8878 
office✉: ArtCom GmbH, Haferwende 2, D-28357 Bremen, Germany
☎:+49-421-20419-0 <http://www.artcom-gmbh.de/>

Attachment: signature.asc
Description: Digital signature


Reply to: