grub2: gecryptete Boot-Partition

cve · 28 Juni 2013

Moin *,

ich versuche ein Setup mt Wheezy, welches grub2, LVM, dm_crypt und md_adm kombiniert. Ein solches Setup läuft hier in ähnlicher Ausführung schon länger sehr zufriedenstellend. Die bestehende Installation ähnelt dem hier:
http://dhost.info/baxic/debian-on-hp-probook-4520s/encrypt.php
Bislang liegt /boot dabei aber auf einer unverschlüsselten seperaten Partition (sda1), wie in obigem Beispiel.

Im Gegensatz zu dem bekannten Setup möchte ich nun auch /boot im gecrypteten Bereich ablegen!

Um das zu testen, habe ich mit VirtualBox eine Maschine aufgebaut mit zwei Disks (Raid1) und mit dem Installer von Wheezy die Konfiguration aufgebaut. Für den Installer war es überhaupt kein Thema, /boot im gecrypteten Bereich anzulegen. Alles lief fehlerfrei durch, bis zu dem Moment, an dem Grub eingerichtet werden sollte.

Die Fehlermeldung:

Code:

Jun 28 09:27:21 grub-installer: info: Installing grub on '/dev/sda'
Jun 28 09:27:21 grub-installer: info: grub-install supports --no-floppy
Jun 28 09:27:21 grub-installer: info: Running chroot /target grub-install  --no-floppy --force "/dev/sda"
Jun 28 09:27:23 grub-installer: /usr/sbin/grub-probe: error:
Jun 28 09:27:23 grub-installer:  
Jun 28 09:27:23 grub-installer: no such disk
Jun 28 09:27:23 grub-installer: .
Jun 28 09:27:23 grub-installer: Auto-detection of a filesystem of /dev/mapper/system-boot1 failed.
Jun 28 09:27:23 grub-installer: Try with --recheck.
Jun 28 09:27:23 grub-installer: If the problem persists please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>
Jun 28 09:27:23 grub-installer: error: Running 'grub-install  --no-floppy --force "/dev/sda"' failed.

RAID:

Code:

Personalities : [raid1] 
md0 : active raid1 sdb1[1] sda1[0]
      15718272 blocks super 1.2 [2/2] [UU]

Code:

# mdadm -Evvs
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : b9ef889f:143553b4:54f0fd88:1f589394
           Name : debian-m90:0  (local to host debian-m90)
  Creation Time : Fri Jun 28 10:05:41 2013
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 31436800 (14.99 GiB 16.10 GB)
     Array Size : 15718272 (14.99 GiB 16.10 GB)
  Used Dev Size : 31436544 (14.99 GiB 16.10 GB)
    Data Offset : 16384 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : e6494e94:295a5615:9f153d21:62c43c88

    Update Time : Fri Jun 28 13:18:35 2013
       Checksum : 1b9d9291 - correct
         Events : 19


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)
/dev/sdb:
   MBR Magic : aa55
Partition[0] :     31453184 sectors at         2048 (type fd)
/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : b9ef889f:143553b4:54f0fd88:1f589394
           Name : debian-m90:0  (local to host debian-m90)
  Creation Time : Fri Jun 28 10:05:41 2013
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 31436800 (14.99 GiB 16.10 GB)
     Array Size : 15718272 (14.99 GiB 16.10 GB)
  Used Dev Size : 31436544 (14.99 GiB 16.10 GB)
    Data Offset : 16384 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 234d6911:e8de8fe6:e7a2b313:f9d8f736

    Update Time : Fri Jun 28 13:18:35 2013
       Checksum : b23bc6b - correct
         Events : 19


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing)
/dev/sda:
   MBR Magic : aa55
Partition[0] :     31453184 sectors at         2048 (type fd)

dm_crypt:

Code:

unused devices: <none>
/dev/mapper/md0_crypt is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/md0
  offset:  4096 sectors
  size:    31432448 sectors
  mode:    read/write

LVM: Es wurden jeweils 2 LVs für /boot und / für eine MultiBoot-Installation vorgesehen. Verwendung findet hier 'boot1' und 'root1'.

Code:

  LV    VG     Attr     LSize   Pool Origin Data%  Move Log Copy%  Convert
  boot1 system -wi-ao-- 488.00m                                           
  boot2 system -wi-a--- 488.00m                                           
  home  system -wi-ao--   1.91g                                           
  root1 system -wi-ao--   5.59g                                           
  root2 system -wi-a---   5.59g                                           
  swap  system -wi-ao-- 976.00m

Code:

  PV                    VG     Fmt  Attr PSize  PFree
  /dev/mapper/md0_crypt system lvm2 a--  14.98g    0

Code:

  --- Logical volume ---
  LV Path                /dev/system/boot1
  LV Name                boot1
  VG Name                system
  LV UUID                sU0iA8-Ndjw-3PMf-xCKz-tHb7-1AZl-3qtuDE
  LV Write Access        read/write
  LV Creation host, time debian-m90, 2013-06-28 10:09:20 +0200
  LV Status              available
  # open                 1
  LV Size                488.00 MiB
  Current LE             122
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
   
  --- Logical volume ---
  LV Path                /dev/system/boot2
  LV Name                boot2
  VG Name                system
  LV UUID                y2hoxD-GN4n-mHvm-OceY-xo3L-0vMK-00jCg1
  LV Write Access        read/write
  LV Creation host, time debian-m90, 2013-06-28 10:09:41 +0200
  LV Status              available
  # open                 0
  LV Size                488.00 MiB
  Current LE             122
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2
   
  --- Logical volume ---
  LV Path                /dev/system/root1
  LV Name                root1
  VG Name                system
  LV UUID                NtQCOo-PlK8-1nQ9-FSfI-aewq-EsYd-PxLG0G
  LV Write Access        read/write
  LV Creation host, time debian-m90, 2013-06-28 10:10:30 +0200
  LV Status              available
  # open                 1
  LV Size                5.59 GiB
  Current LE             1430
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3
   
  --- Logical volume ---
  LV Path                /dev/system/root2
  LV Name                root2
  VG Name                system
  LV UUID                ChV03O-PRiM-9rGE-gxgv-sHf2-ILEA-9L7RTq
  LV Write Access        read/write
  LV Creation host, time debian-m90, 2013-06-28 10:10:56 +0200
  LV Status              available
  # open                 0
  LV Size                5.59 GiB
  Current LE             1430
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:4
   
  --- Logical volume ---
  LV Path                /dev/system/swap
  LV Name                swap
  VG Name                system
  LV UUID                1WSNyX-rnAN-Thyd-Jd41-81Wp-3mYm-irKXqn
  LV Write Access        read/write
  LV Creation host, time debian-m90, 2013-06-28 10:12:37 +0200
  LV Status              available
  # open                 2
  LV Size                976.00 MiB
  Current LE             244
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:5
   
  --- Logical volume ---
  LV Path                /dev/system/home
  LV Name                home
  VG Name                system
  LV UUID                GggO0c-oBPT-JKQb-NioT-TRCN-gjL1-GkKYOH
  LV Write Access        read/write
  LV Creation host, time debian-m90, 2013-06-28 10:12:54 +0200
  LV Status              available
  # open                 1
  LV Size                1.91 GiB
  Current LE             488
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:6

Code:

Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/system-root1  5.5G  3.6G  1.7G  69% /
/dev/mapper/system-boot1  473M   29M  420M   7% /boot
/dev/mapper/system-home   1.9G   35M  1.8G   2% /home
tmpfs                     502M     0  502M   0% /dev

Ich meine, gelesen zu haben, dass mit grub2 nun alles beisammen wäre für ein solches Setup. Gibt es eine Chance, /boot ebenfalls per crypt zu schützen?

Bitte um Hilfe...
TNX

cu, cve

cve · 30 Juni 2013

Bislang leider noch gar keine Antwort...

Muß ich daraus schliessen, dass so etwas gar nicht geht? Oder hat sich da noch niemand ran getraut? Oder ist die kryptographische Absicherung des Kernels Eurer Meinung nach schlichtweg überflüssig?
TNX

cu, cve

cve · 30 Juni 2013

http://unix.stackexchange.com/questions/30120/linux-boot-loaders-supporting-full-disk-encryption

RME · 30 Juni 2013

Hallo,

The Problems with Full Disk Encryption

>>> http://www.stealth-x.com/articles/the-problems-with-full-disk-encryption.php

There's no security like physical security

What you have to do is make it so its impossible to edit the kernel. To do so, you have to keep the kernel on you at all times. No, I dont mean sticking your laptop up your shirt to go to work, I mean installing your kernel and boot loader onto a USB stick that you can carry around with you around your neck or in your pocket.

Gruss,
Roland

Anonymous · 30 Juni 2013

cve schrieb:
Muß ich daraus schliessen, dass so etwas gar nicht geht? Oder hat sich da noch niemand ran getraut? Oder ist die kryptographische Absicherung des Kernels Eurer Meinung nach schlichtweg überflüssig?

Die Dateien die unterhalb von /boot stehen kann sowieso jeder auf jeder vergleichbaren Maschine im Klartext lesen oder sich herunterladen. Die sind also nicht so interessant das du als der einzige auf der Welt die unbedingt schützen solltest. Warum das also verschlüsseln. Interessant wäre nur der Kernel und die Initrd und zwar auch nur aus dem Grund damit die dir niemand offline auswechselt ohne das du das mit bekommst.

Aber wer sagt denn das ich den Kernel auch im selben /boot wie die Grub Dateien ablegen musst. Grub2 sollte verschlüsselte Partitionen selber lesen können, also sollte es irgendwie machbar sein den Kernel und die Initrd in ein verschlüsseltes /boot Verzeichnis auf der Rootpartition zu haben und ein unverschlüsseltes /boot auf einer separaten Partition wo nur die Grub2 Dateien sind. Schwierig wird wahrscheinlich nur dieses deinem System zu erklären, damit auch ein Kernel- und grub2-Updates und ähnliches sauber funktionieren und dabei der Kernel und die initrd nicht in das unverschlüsselte /boot abgelegt wird, aber Grub2-Anderungen nicht in das verschlüsselte /boot zu schreiben. Ob das schon jemand ausprobiert hat ??????

Als Alternative bleibt immer die viel einfachere Handhabung einer FDE-Disk. Die sollte es mittlerweile auch schon von den meisten Herstellern geben.

robi

cve · 30 Juni 2013

Moin robi,

vielen Dank für Deine Antwort.

robi schrieb:
Interessant wäre nur der Kernel und die Initrd und zwar auch nur aus dem Grund damit die dir niemand offline auswechselt ohne das du das mit bekommst.

Genau um letzteren Punkt geht es mir: Das jemand den vorhandenen gegen einen trojanisierten Kernel austauscht (während physischer Zugriff besteht).

robi schrieb:
Aber wer sagt denn das ich den Kernel auch im selben /boot wie die Grub Dateien ablegen musst. Grub2 sollte verschlüsselte Partitionen selber lesen können, also sollte es irgendwie machbar sein den Kernel und die Initrd in ein verschlüsseltes /boot Verzeichnis auf der Rootpartition zu haben und ein unverschlüsseltes /boot auf einer separaten Partition wo nur die Grub2 Dateien sind. Schwierig wird wahrscheinlich nur dieses deinem System zu erklären, damit auch ein Kernel- und grub2-Updates und ähnliches sauber funktionieren und dabei der Kernel und die initrd nicht in das unverschlüsselte /boot abgelegt wird, aber Grub2-Anderungen nicht in das verschlüsselte /boot zu schreiben. Ob das schon jemand ausprobiert hat ??????

Dieser Frage schliesse ich mich an. Gerne mit Unterstützung durch die Distribution...

robi schrieb:
Als Alternative bleibt immer die viel einfachere Handhabung einer FDE-Disk. Die sollte es mittlerweile auch schon von den meisten Herstellern geben.

Du meinst die Dinger, die als geschlossenes System direkt von der guten NSA zu uns geschickt werden?

cve · 30 Juni 2013

Moin Roland

RME schrieb:
There's no security like physical security

What you have to do is make it so its impossible to edit the kernel. To do so, you have to keep the kernel on you at all times. No, I dont mean sticking your laptop up your shirt to go to work, I mean installing your kernel and boot loader onto a USB stick that you can carry around with you around your neck or in your pocket.

Zum Vergrößern anklicken....

Vielen Dank für den sehr aufschlussreichen Link - den muß ich erst mal verdauen. Bin ein paar Tage offline, melde mich evtl. danach noch mal...
TNX

cu, cve

Schweineschwarte · 17 Juli 2013

Um den Bootloader vor Veränderungen zu schützen gibt es auch noch die Prüfsummen. Pro-Linux.de hatte das einmal recht gut beschrieben:
http://www.pro-linux.de/artikel/2/131/2,checksummen-mit-md5.html
Ich denke wenn das System vollverschlüsselt ist (außer die boot-Partition), brauch man auch nicht alle Dateien in den aufgelisteten Ordnern von Pro-Linux auf Veränderungen überprüfen, sondern nur die Dateien im /boot-Verzeichnis. Dazu würde es denke ich sogar reichen, wenn man das Prüfsummenprogramm (sha512sum) und die Vergleichstextdatei mit den Prüfsummen der Dateien auf der lokalen Festplatte liegen lässt. Die Festplatte ist schließlich verschlüsselt und könnte wenn dann nur über das Internet verändert werden, aber wenn der Angreifer das schafft, dann ist er ja schon auf eurem Rechner und brauch sich keine Mühe mehr mit dem Verändern des boot-Verzeichnisses machen.
Das Prüfsummenprogramm sollte dann natürlich nach jedem Rechnerstart das boot-Verzeichnis überprüfen. Sollte ein Angreifer dieses verändert haben würde es nun auffallen.

Was mich persönlich allerdings noch interessiert, ist ob TrueCrypt bei einer Vollverschlüsselung unter Windows ebenfalls sein Bootloader-Verzeichnis auf Veränderungen überprüft oder es einfach dabei belässt? Hat dazu jemand mehr Wissen und/oder Infos/Quellen?

Danke!

cve · 19 Juli 2013

Schweineschwarte schrieb:
Um den Bootloader vor Veränderungen zu schützen gibt es auch noch die Prüfsummen. Pro-Linux.de hatte das einmal recht gut beschrieben:
http://www.pro-linux.de/artikel/2/131/2,checksummen-mit-md5.html

Auch die c't hatte da einen Artikel in 03/2012.

Schweineschwarte schrieb:
Ich denke wenn das System vollverschlüsselt ist (außer die boot-Partition), brauch man auch nicht alle Dateien in den aufgelisteten Ordnern von Pro-Linux auf Veränderungen überprüfen, sondern nur die Dateien im /boot-Verzeichnis. Dazu würde es denke ich sogar reichen, wenn man das Prüfsummenprogramm (sha512sum) und die Vergleichstextdatei mit den Prüfsummen der Dateien auf der lokalen Festplatte liegen lässt. Die Festplatte ist schließlich verschlüsselt und könnte wenn dann nur über das Internet verändert werden, aber wenn der Angreifer das schafft, dann ist er ja schon auf eurem Rechner und brauch sich keine Mühe mehr mit dem Verändern des boot-Verzeichnisses machen.
Das Prüfsummenprogramm sollte dann natürlich nach jedem Rechnerstart das boot-Verzeichnis überprüfen. Sollte ein Angreifer dieses verändert haben würde es nun auffallen.

Das sehe ich kritisch. Gesetzt den Fall, der Angreifer hat auf dem Wege des physischen Zugriffes erfolgreich ein Rootkit untergeschoben, dann kann dieses schlichtweg alles zur Laufzeit manipulieren und Du wirst nichts davon mitbekommen.
Wenn Zugriff auf den Kernel bestand, ist IMHO prinzipiell alles möglich und somit Hopfen und Malz verloren. Ich bin mittlerweile davon überzeugt, dass man hier radikaler vorgehen muß. Beispielsweise '/boot' komplett auslagern und physisch absichern.

cu, cve

cve · 19 Juli 2013

cve schrieb:
Wenn Zugriff auf den Kernel bestand, ist IMHO prinzipiell alles möglich und somit Hopfen und Malz verloren. Ich bin mittlerweile davon überzeugt, dass man hier radikaler vorgehen muß. Beispielsweise '/boot' komplett auslagern und physisch absichern.

Ich habe hierzu mal als Vorschlag ein Setup konfiguriert, welches bei mir seit letzter Woche läuft - bislang bin ich zufrieden damit. Bitte schaut doch mal drauf:
http://www.linupedia.org/opensuse/Partitionierung_eines_komplett_verschlüsselten_Linux-Systems
TNX

cu, cve

Schweineschwarte · 19 Juli 2013

Ich hab mich noch nicht so intensiv mit ,Suspend-To-RAM' beschäftigt, aber hierbei werden dann doch alle wichtigen Daten im Arbeitsspeicher gesichert oder? Das würde doch heißen, dass auch das Kennwort für die Verschlüsselung (von dm-crypt) sowie vielleicht auch noch zuletzt verwendete Daten weiterhin im Arbeitsspeicher liegen, wenn der Rechner sich im ,Suspend-To-RAM' befindet. Das wäre jedoch ein Sicherheitsrisiko, da sie mittels eines Kaltstartangriffes ausgelesen werden könnten --> http://www.truecrypt.org/docs/unencrypted-data-in-ram
Von daher wäre es vielleicht sinnvoll noch eine Bemerkung an der Stelle im Wiki zu machen, dass ,Suspend-To-RAM' nicht empfohlen wird, wenn man eine Vollverschlüsselung nutzt.

Ach meinst du es wäre für andere Nutzer hilfreich noch einen Verweis auf die Prüfsummenmöglichkeit nach Pro-Linux zu verweisen? Diese Methode bietet und zwar keinen Schutz vor Infizierung, aber hilft dabei eine Infizierung zu erkennen und dürfte vielleicht für manche etwas einfacher oder bequemer sein als seine boot-Partition auf einem extra Speichermedium auszulagern?

cve · 19 Juli 2013

Schweineschwarte schrieb:
Ich hab mich noch nicht so intensiv mit ,Suspend-To-RAM' beschäftigt, aber hierbei werden dann doch alle wichtigen Daten im Arbeitsspeicher gesichert oder? Das würde doch heißen, dass auch das Kennwort für die Verschlüsselung (von dm-crypt) sowie vielleicht auch noch zuletzt verwendete Daten weiterhin im Arbeitsspeicher liegen, wenn der Rechner sich im ,Suspend-To-RAM' befindet. Das wäre jedoch ein Sicherheitsrisiko, da sie mittels eines Kaltstartangriffes ausgelesen werden könnten --> http://www.truecrypt.org/docs/unencrypted-data-in-ram
Von daher wäre es vielleicht sinnvoll noch eine Bemerkung an der Stelle im Wiki zu machen, dass ,Suspend-To-RAM' nicht empfohlen wird, wenn man eine Vollverschlüsselung nutzt.

Danke für Dein Review.

Du meinst hier einen Angriff wie 'ganz schnell RAMs rausnehmen, irgendwo reinstecken und den Inhalt mitsamt CryptKey auslesen, um damit dann auf die verschlüsselten Daten zuzugreifen. Vorzugsweise bei sehr niedrigen Temperaturen...'???

Dagegen hilft die hier vorgestellte Vorgehensweise überhaupt nicht - aber dafür ist das auch gar nicht gedacht. Ein solcher Angriff ist möglich, darauf wird ja auch in den enthaltenen Links hingewiesen (und ich war verblüfft, wie lange RAMs die Informationen behalten).

Aber ich denke, dass das Vermeiden von Suspend-To-RAM hier auch keinen Schutz bietet. Was sollte den Angreifer daran hindern, einen solchen Angriff bei einem laufenden, aber gesperrten und unbeaufsichtigten System durchzuführen? Wenn man so etwas verhindern will, müssen IMHO ganz andere Maßnahmen ergriffen werden. Frag mich nicht, welche...

cu, cve

Schweineschwarte · 19 Juli 2013

Nee, mit Kaltstartangriff (cold boot attack) meine ich was anderes.
Du hast ja im Wiki geschrieben:

Im konkreten Fall eines Notebooks fallen diese Kriterien aber im laufenden Betrieb kaum ins Gewicht, insbesondere weil das System relativ selten tatsächlich gebootet wird. Stattdessen kommt sehr häufig 'Suspend-To-RAM (STR)' zum Einsatz, bei welchem ein Bootvorgang nicht notwendig ist.

Wenn man den Rechner nun aber nicht immer ausschaltet, sondern die Daten im Arbeitsspeicher liegen lässt, bietet dies eine Angriffsfläche, wenn der Rechner so in falsche Hände kommt.
Es würde so ablaufen, dass man den Rechner schnell ausschaltet und sofort wieder neu hochfährt, um anschließend ein Minibetriebssystem zu starten mit welchem man den Arbeitsspeicher ausliest und analysiert und so an den Schlüssel für die Vollverschlüsselung und ggf. noch an weitere empfindliche Daten kommen kann.
Deswegen sollte man den Rechner immer richtig ausschalten, wenn man ihn nicht mehr benötigt (z.B. über Nacht).
Dies ist sehr wichtig, da wie in deinem Artikel beschrieben es nicht darum geht den Rechner vor Verlust zu schützen, sondern vor lokalem Zugriff, z.B. durch Geheimdienste oder morgentliche Durchsuchungen vom Staatsschutz.
https://de.wikipedia.org/wiki/Kaltstartattacke

cve · 19 Juli 2013

Schweineschwarte schrieb:
Nee, mit Kaltstartangriff (cold boot attack) meine ich was anderes.

Das ist doch genau der von mir skizzierte Angriff.

Schweineschwarte schrieb:
Du hast ja im Wiki geschrieben:

Im konkreten Fall eines Notebooks fallen diese Kriterien aber im laufenden Betrieb kaum ins Gewicht, insbesondere weil das System relativ selten tatsächlich gebootet wird. Stattdessen kommt sehr häufig 'Suspend-To-RAM (STR)' zum Einsatz, bei welchem ein Bootvorgang nicht notwendig ist.

Zum Vergrößern anklicken....

Wenn man den Rechner nun aber nicht immer ausschaltet, sondern die Daten im Arbeitsspeicher liegen lässt, bietet dies eine Angriffsfläche, wenn der Rechner so in falsche Hände kommt.
Es würde so ablaufen, dass man den Rechner schnell ausschaltet und sofort wieder neu hochfährt, um anschließend ein Minibetriebssystem zu starten mit welchem man den Arbeitsspeicher ausliest und analysiert und so an den Schlüssel für die Vollverschlüsselung und ggf. noch an weitere empfindliche Daten kommen kann.
Deswegen sollte man den Rechner immer richtig ausschalten, wenn man ihn nicht mehr benötigt (z.B. über Nacht).
Dies ist sehr wichtig, da wie in deinem Artikel beschrieben es nicht darum geht den Rechner vor Verlust zu schützen, sondern vor lokalem Zugriff, z.B. durch Geheimdienste oder morgentliche Durchsuchungen vom Staatsschutz.
https://de.wikipedia.org/wiki/Kaltstartattacke

Wie geschrieben: Ja, das geht. Aber das geht auch dann, wenn der Rechner läuft. Als Konsequenz dürfte man nie seinen Rechner unbeaufsichtigt laufen lassen.
Und im Falle des Staatsschutzes hilft ja auch noch nicht mal die Beaufsichtigung etwas, wenn man zum Zeitpunkt des Eintreffens der Beamten direkt am laufenden System sitzt. Während Du mit Handschellen auf dem Boden liegst, packen die Kollegen Dein Notebook schon in den flüssigen Stickstoff...

OK. Ich werde noch einen entsprechenden Hinweis hinzufügen. Dann kann jeder sein persönliches Risiko abwägen.
TNX

cu, cve

Schweineschwarte · 19 Juli 2013

Naja es ist schon ein Unterschied ob sie mit einem Stickstoffbehälter bei dir sind oder einfach nur mit einer CD von der sie starten

(letztere ist deutlich preiswerter)
Wenn dein Rechner über Nacht richtig aus war, dann werden sie auch im Arbeitsspeicher nichts mehr finden. Bei ,Suspend-To-RAM' dürfte das vermutlich anders aussehen.

cve · 19 Juli 2013

Schweineschwarte schrieb:
Naja es ist schon ein Unterschied ob sie mit einem Stickstoffbehälter bei dir sind oder einfach nur mit einer CD von der sie starten (letztere ist deutlich preiswerter)
Wenn dein Rechner über Nacht richtig aus war, dann werden sie auch im Arbeitsspeicher nichts mehr finden. Bei ,Suspend-To-RAM' dürfte das vermutlich anders aussehen.

Noch einmal: Gegen diese Art von Angriffen kann man sich mit dem Setup nicht wehren. Aber dieses von Dir angeführte Beispiel ist ungeeignet, weil die Staatsmacht ebenso gut einen laufenden Rechner angreifen kann, wenn sie nicht morgens um Vier, sondern beispielsweise kurz vor der Mittagspause aufläuft. Irgendwann mußt Du deinen Rechner ja mal anmachen. Das grundsätzliche Risiko bleibt, aber das ist IMHO eine andere Baustelle.

Ob man STR einsetzt ist Ermessenssache: Höhere Sicherheit vs. höhere Produktivität.

Anonymous · 20 Juli 2013

Na dann spinnen wir mal ein bisschen weiter und überlegen uns wie man eine Kiste noch weiter absichern könnte.

Das folgende ist nicht ganz so erst gemeint, nicht ausprobiert und vor Nachahmung sei dringend gewarnt.

Grundlage: das Vollverschlüsselte System ohne verschlüsseltes /boot.
* Im Bios erlauben wir nur booten von dieser Platte. und Biospasswort drauf.
* In Grub2 brauchen wir ein Passwort zum booten, dieses wollen wir uns aber nicht merken. Am besten wir nehmen dazu Herstellerangaben wie zB. Seriennummer oder nur Herstellername von Tastatur,Maus oder Bildschrim. (mittelgroße Änderung in Grub2 notwendig)
* Den CryptKey für das Linuxsystem wollen wir uns auch gar nicht merken, dafür nutzen wir die Seriennummer vom Systemboard ( kleine zusätzliche Änderung in Grub2)

Damit bootet das System schon mal von ganz alleine. Voraussetzung Maus/Tastatur/Bildschirm wurde nicht gewechselt und es wird nicht versucht mit der Platte oder einem Image davon auf einem anderem Rechner zu booten. Die Passwörter sind sicher, die kannst du nicht mal unter Folter verraten, da du sie selbst nicht weißt oder schnell vergisst, da du sie nie brauchen wirst. Das BIOS-PW kannst du ruhig unter schwerer Folter verraten (soweit wird es aber nicht kommen "Die" haben sowieso die Masterpasswörter ansonsten ist in jeder Systemboard-Doku nachzulesen wie das zurückgesetzt werden kann), durch den gefakten Grub2-Bootloader der den Key fürs Entschlüsseln automatisch vom Systemboard ermittelt, kann niemand mit einem anderem Bootloader booten und dort ohne weiteres die Platte mounten, also nicht viel damit anfangen.

Zum System selbst.
* Das System läuft nur ohne Netzwerkverbindung. Von den eingebauten Netzwerkkarten werden die passenden Treibermodule unter /lib/modules/... entfernt.
* Sobald irgend ein Netzwerktreiber geladen wird, fährt die Kiste runter/panic oder bootet erst gar nicht, (Script)
* Wird eine 2. oder unbekannte Festplatte gesehen, oder eine CD/DVD/.... oÄ. fährt die Kiste runter/panic oder bootet nicht (Script)
* an den USB Schnittstellen sind Maus und Tastatur erlaubt, Ausnahme an einer einzigen USB-Schnittstelle werden USB-Sticks erlaubt, deren Seriennummer dem Script bekannt ist, und dann wird automatisch versucht dort ein verschlüsseltes Dateisystem zu finden. Funktioniert das nicht, oder wird falsche Passphrase eingegeben, oder irgend etwas anderes dort angeschlossen, fährt die Kiste runter/panic oder bootet erst gar nicht ( wohl ein paar mehr Scripte)
* Serielle Schnittstelle, Firewire und ähnliches wird komplett verboten, sobald dort was steckt, fährt die Kiste runter/panic oder bootet gar nicht.(Script)
* Parallele Schnittstelle, hier verbieten wir auch mit Script alles was nach Drucker aussieht, aber wir erlauben eine Point-to-Point Netzverbindung. Aber im System ist nirgends eine Konfiguration dafür, die muss bei Bedarf von Hand eingegeben werden.

Die ganzen Scripte die dazu benötigt werden sind unkommentiert und sehr kryptisch geschrieben und werden als selbst entpackende und selbst startende komprimierte Scripte ausgelegt, die an den Anfang von vollkommen unauffälligen Binärdateien gesetzt werden. Wird eine solche Binärdatei gestartet, wird automatisch das Script entpackt und gestartet und gleichzeitig auch die originale Binärdatei mit ihrer normalen Funktion.

Damit bist du sicher vor allen Angriffen von außen, wer was von dir wissen will, muss zu dir nach Hause kommen. Kann auch den Rechner problemlos starten, da ja keinerlei Passwort benötigt wird, und kann alles sehen was ihn interessiert oder auch nicht. Allerdings sobald er versucht irgendetwas davon irgend woanders hin zu schreiben, oder dir irgendetwas draufladen will, wird er verzweifeln. Die einzige Möglichkeit sind Bildschirmfotos, aber das ist recht unprofessionell und schlecht automatisch auswertbar also wird er auf diese Idee zu allerletzt kommen. Nach ein paar Stunden vergeblicher Mühe wird er entweder die Platte oder den Rechner mitnehmen, allerdings wird er natürlich Maus/Tastatur/Bildschirm nicht auch noch mit schleppen, und mit all dem kann er so schnell dann aber überhaupt nichts anfangen.

Du selbst hast nur die Möglichkeit über die im Script bekannten USB-Sticks einen verschlüsselten Datenaustausch vorzunehmen oder dir per Hand ein Point-to-Point Netzwerk über die Parallele Schnittstelle für den Datenaustausch zu konfigurieren. Aber dazu braucht man ein spezielle gekreuztes vollverdrahtes Kabel, (ein bestimmter Pin müsste aus dem Stecker ausgebrochen sein), das ist heute eine Rarität und wie man so eine Konfiguration per Hand aufsetzt, ist längst in Vergessenheit geraten. Also selbst NSA-Spezialisten hätten kein Kabel mit und würden auch eine ganze Zeit brauchen bis sie die Konfiguration hinbekommen hätten, mal abgesehen, müssten sie erst mal auf so eine absurde Idee kommen. Und besonders schnell ist es auch nicht und die müssten immer damit rechnen das du ja auch mal wieder nach Hause kommst.

Soweit fertig, bevor du damit arbeitest, erstmal ausprobieren.
Also ein Laptop mit dieser Konfiguration aufsetzen. Günstige Konfiguration jetzt, wenn das Ding nur bootet wenn eine bestimmte Maus eingesteckt ist. (vor der Installation die Platte mit RANDOM überschreiben, damit nicht alte Klartext Spuren vom altem System zwischen den neu verschlüsselte Daten rumliegen)
Auf die Standardinstallation mit der speziellen Konfiguration und den versteckten Scripten kommen jetzt ein paar Verzeichnisse . zB.:
Grundriss/
Bauplan/
Plan-A/
Plan-B/
Afghanistan/
Koran/

dort kommen überall ein paar Bilder hin. Am besten alte Urlaubsphotos wo neben schöner Natur noch ein paar dir absolut unbekannte Leute drauf sind und ein paar Bilder von Nachbars Garten so richtig mit Nachbar drauf, wie er gerade im Garten arbeitet.
In die Bilder packst du jeweils mit steghide eine ca. 1MB große Random-Datei, Passwort nicht vergessen, für jede ein anderes am besten auch Random. Brauchst du dir ja nicht merken.
sonst kommt auf die Kiste nichts weiteres an Dateien.

Wenn soweit fertig, brauchst du ein paar Tage Urlaub und ein bisschen Kleingeld zum ausprobieren. Du buchst irgendwas in USA, Hotel brauchst du nicht und du buchst auch nur Hinflug, für den Rückflug nimmst du das Geld vorsichtshalber aber mal mit.
Dann packst du deine Koffer, Laptop nicht vergessen und setzt dich in den Flieger.

Wenn dich jemand nach deinem Laptop fragt, wissen will was drauf ist, dann bist du sehr kooperativ, du zeigst auch gerne wie schön es bootet und zeigst alle Bilder und erzählst was es dort zu sehen gibt. Nicht vergessen, Ziel der USA-Reise ist das Laptop zu testen (das sagst du so natürlich nicht, du willst Urlaub machen), also wenn sie dich nicht freiwillig auf den Kicker haben sollten , dann ruhig mal bei der Ankunft beim Zoll auf das Laptop zeigen und höflich nachfragen ob du dich nicht mal schnell mit dem Intranet vom Flughafen verbinden darfst, du muss dringend eine Mail losschicken. Wenn sich jemand das Laptop mal ausleihen will, bitte, Maus behältst natürlich du, aber du willst unbedingt darauf warten, du brauchst es nämlich dringend.
Wenn Fragen zu den Bildern kommen, alles wahrheitsgetreu beantworten, wo und wann aufgenommen, Name und Adresse der darauf befindlichen Personen, und wie lange du sie schon kennst, usw. Da du ja nur den Nachbarn kennst, kann die Fragestunde ja nicht lange dauern, und du musst auch dringend weiter und willst unbedingt das Laptop mitnehmen, da dir die Bilder schrecklich wichtig sind.
Damit solltest du jetzt ihre volle Aufmerksamkeit haben, und sie wollen gerne das du deine Bilder mit ihnen teilst. Jetzt drückst du die Stoppuhr und schaust wie lange es ab jetzt noch dauert.

Ergebnisüberprüfung:
Wenn du wider Erwarten doch ein Hotel brauchst, stimmt was noch nicht.
Ansonsten wenn die Rückreise über Guantanamo führt, oder du länger als 5 Tage brauchst bis du wieder zu Hause bist und dabei außer dem Flughafen nichts gesehen hast, das Laptop nicht mehr da ist und du obendrein noch der Meinung bist alle Amerikaner sind extrem unfreundlich, oder bei deiner Rückkehr der Nachbar verschwunden ist, oder sich seltsam benimmt, oder von komischen Sachen redet. Dann ist das Konzept perfekt.

robi

cve · 20 Juli 2013

robi schrieb:
Na dann spinnen wir mal ein bisschen weiter und überlegen uns wie man eine Kiste noch weiter absichern könnte.

Das folgende ist nicht ganz so erst gemeint, nicht ausprobiert und vor Nachahmung sei dringend gewarnt.

[...]

oder bei deiner Rückkehr der Nachbar verschwunden ist, oder sich seltsam benimmt, oder von komischen Sachen redet. Dann ist das Konzept perfekt.

ROTFL - Du hast mir den Tag gerettet...

cu, cve

Schweineschwarte · 20 Juli 2013

Haha mir auch!

grub2: gecryptete Boot-Partition

cve

Newbie

cve

Newbie

cve

Newbie

RME

Advanced Hacker

Anonymous

Gast

cve

Newbie

cve

Newbie

Schweineschwarte

Member

cve

Newbie

cve

Newbie

Schweineschwarte

Member

cve

Newbie

Schweineschwarte

Member

cve

Newbie

Schweineschwarte

Member

cve

Newbie

Anonymous

Gast

cve

Newbie

Schweineschwarte

Member