# Wie habt Ihr euer System abgesichert/verschlüsselt?

## SarahS93

Was für ein System habt Ihr / welche Aufgaben wickelt es ab und wie habt ihr es abgesichert bzw. verschlüsselt?

----------

## hafgan

 *SarahS93 wrote:*   

> Was für ein System habt Ihr / welche Aufgaben wickelt es ab und wie habt ihr es abgesichert bzw. verschlüsselt?

 

Nur Laptop: 

Falls es mal verloren/gestohlen werden sollte. 

Das Benutzerverzeichnis wurde mit ecrpytfs verschlüsselt.

Unter Gentoo macht mir allerdings noch die Einbindung einer verschlüsselten SWAP Schwierigkeiten. Daher lass ich SWAP komplett weg. (Mit 8GB ist das bisher nicht problematisch gewesen).

----------

## toralf

[quote="hafgan"] *SarahS93 wrote:*   

> Unter Gentoo macht mir allerdings noch die Einbindung einer verschlüsselten SWAP Schwierigkeiten. 

 Ups, genau das ging bei mir problemlos:

```
n22kvm ~ # grep -v -e '#' -e '^$' /etc/conf.d/dmcrypt

swap=crypt-swap

source='/dev/sda3'

n22kvm ~ # grep swap /etc/fstab

#/dev/vda3              none            swap            sw              0 0

/dev/mapper/crypt-swap  swap            swap            defaults        0 0

n22kvm ~ # zgrep CONFIG_DM_CR /proc/config.gz

CONFIG_DM_CRYPT=m

```

----------

## hafgan

@Toralf: So hatte ich es geplant. Ich werde der Sache nochmal nachgehen! - Danke!

----------

## Erdie

Meinen Desktop habe ich gar nicht verschlüsseln, noch nicht mal ein Login Passwort. Für etwas empfindlichere Daten habe ich einen Bereich, der mit encfs verschlüsselt ist. Der wird bei Bedarf mal gemounted.

----------

## forrestfunk81

Bei Laptop, Desktop und Homeserver / Router sind die Root, Swap, Home und Daten Partitionen verschlüsselt mit LUKS (twofish-xts-essiv:sha512). VServer und Raspberry sind unverschlüsselt.

----------

## cryptosteve

Alle meine Rechner sind mit luks/lvm verschlüsselt. Besonders sensible Daten liegen darüber hinaus nochmal in einem encfs, dass nur für den Zeitpunkt des Zugriffs aufgeschlossen wird. gnupg und otr kommen für Kommunikation immer dann zum Einsatz, wenn die Gegenstelle es versteht.

Mir würde sogar der Diebstahl meiner 10kg Desktopkiste Bauchschmerzen bereiten. Ich habe ein sehr gutes luks-Passwort (>20 Zeichen), und dafür dann kein Anmeldepasswort mehr (Autologin).

Btw: dieser Thread hätte besser ins Diskussionsforum gepasst.  :Smile: 

----------

## Finswimmer

Ich habe nur meinen Laptop verschlüsselt.

Der Key liegt auf einem USB-Stick in einem "Hidden" Bereich und ist mit GPG verschlüsselt.

Im Safe liegt natürlich noch der Key im Klartext.

Moved from Deutsches Forum (German) to Diskussionsforum.

----------

## kurisu

Unabhängig davon, ob die Daten als sensibel einzuordnen sind oder nicht, sind all meine Rechner grundsätzlich mit aes-xts-plain64:sha512 über LUKS verschlüsselt. Für Daten, die in meinen Augen sensibel sind, verwende ich zusätzlich ecryptfs.

----------

## Yamakuzure

Grundsicherung:

-------------------

Drei unterschiedliche Passwörter für das Einschalten, das BIOS, sowie den Festplattencontroller und die Festplatte.

Bei den DELL Notebooks ist ganz praktisch, dass selbst wenn jemand für die Festplatte das Backdoor-Passwort von DELL kennen würde, die Freigabe erst nach einem vollständigen Löschen der Festplatte erfolgt.

Ferner ist das Ding auch noch doppelt gesichert. Die Festplatte kann an einem anderen Controller nicht verwendet werden, und eine andere Festplatte nicht an diesem Controller.

Außerdem hat das Gerät noch eine interessante Diebstahlsicherung, mit der ein geklautes Laptop binnen Minuten per GPS ausfindig gemacht werden kann. Egal ob es eingeschaltet ist oder nicht.

Daten:

--------

Ich habe zwei Sätze Truecrypt Container.

Der Erste mit 6 Containern ist für meine diversen Backup Ordner gedacht. Diese synchronisiere ich mit Copy.com. Backups gehen mir also nie verloren, und niemand kann aus der Cloud heraus darauf zugreifen.

Der Zweite mit 7 Containern ist für meine beruflichen und privaten Daten, sowie E-Mails, Notizen, Kalender, halt das KDE-PIM Zeugs.

Nach dem Hochfahren des Laptops muss ein Skript gestartet werden, sonst ist alles leer und nutzlos.  :Wink:  Und natürlich muss ich dafür auch immer brav das Passwort von Hand eingeben.

Die 6 Container werden in ein raidz1 (5 + 1 Spare), die 7 Container in ein raidz2 (6 + 1 Spare) eingehängt und dann mittles ZFS gemountet. Mit etwas Anderem wäre das, was ich da mache, auch garnicht möglich.

Swap:

-------

swap ist bei mir nicht verschlüsselt, sondern wird durch 8 zram devices (1 pro CPU) geregelt. Ich wüsste auch nicht, wofür ich das verschlüsseln sollte, ich habe 32GB RAM, und baue alles in einem tmpfs Laufwerk. Aber wirklich gebraucht habe ich swap bislang erst einmal, was damals an ccache lag. Im swap steht dann nun wirklich nichts Wichtiges drin.

Heutzutage ist das für mich auch schwer zu verstehen, wofür man swap verschlüsseln sollte. Auf einem Dektop/Notebook mit mehr als 512MB RAM setzt man vm.swappiness in der /etc/sysctl.conf doch eh immer auf 0. Wie soll dann da irgendetwas Relevantes reinkommen? Aber das ist wahrscheinlich eh eher philosophisch.

Passwörter:

--------------

Alle Passwörter bei mir haben mindestens 10 Stellen und bestehen aus Großbuchstaben, Kleinbuchstaben, Sonderzeichen und Zahlen. Ein Extra Truecrypt Container mit den wichtigen privaten Daten habe ich auch noch, das Passwort hat 30 Stellen.

Sollte mir jemand das Ding im Laufenden Betrieb klauen und irgend eines der Passwörter, bevor der Akku alle ist oder die Polizei vor der Tür steht, geknackt bekommen, wäre ich wahrscheinlich eher beeindruckt als sauer.  :Wink: 

----------

## forrestfunk81

 *Yamakuzure wrote:*   

> 
> 
> Heutzutage ist das für mich auch schwer zu verstehen, wofür man swap verschlüsseln sollte. Auf einem Dektop/Notebook mit mehr als 512MB RAM setzt man vm.swappiness in der /etc/sysctl.conf doch eh immer auf 0. Wie soll dann da irgendetwas Relevantes reinkommen? Aber das ist wahrscheinlich eh eher philosophisch.
> 
> 

 

Der Rechner könnte ja genau in dem Moment abstürzen, wenn der Speicher knapp wird und ein paar MB in den Swap geschrieben werden. Und dann stehen die bösen Jungs vor der Tür  :Smile: 

Deshalb: Sicher ist sicher und es macht ja keinen großen Aufwand das auch zu verschlüsseln. 

 *Yamakuzure wrote:*   

> 
> 
> Sollte mir jemand das Ding im Laufenden Betrieb klauen und irgend eines der Passwörter, bevor der Akku alle ist oder die Polizei vor der Tür steht, geknackt bekommen, wäre ich wahrscheinlich eher beeindruckt als sauer. 

 

Das seh ich auch so. Bei dem Szenario fürchte ich am meisten Bugs im Screensaver, wie wir es vor zwei, drei Jahren mal hatten.

----------

## Yamakuzure

 *forrestfunk81 wrote:*   

>  *Yamakuzure wrote:*   
> 
> Heutzutage ist das für mich auch schwer zu verstehen, wofür man swap verschlüsseln sollte. Auf einem Dektop/Notebook mit mehr als 512MB RAM setzt man vm.swappiness in der /etc/sysctl.conf doch eh immer auf 0. Wie soll dann da irgendetwas Relevantes reinkommen? Aber das ist wahrscheinlich eh eher philosophisch.
> 
>  
> ...

 Da hast du natürlich Recht, auch wenn das die Wahrscheinlichkeit eines solchen Szenarios bei meinen 32GB RAM streng gegen Null geht.

Aber aus reiner Neugier: Wie verschlüssel ich ZRAM-Swap? Sollte von der Performance her ja kein Problem sein.

 *forrestfunk81 wrote:*   

>  *Yamakuzure wrote:*   
> 
> Sollte mir jemand das Ding im Laufenden Betrieb klauen und irgend eines der Passwörter, bevor der Akku alle ist oder die Polizei vor der Tür steht, geknackt bekommen, wäre ich wahrscheinlich eher beeindruckt als sauer.  
> 
> Das seh ich auch so. Bei dem Szenario fürchte ich am meisten Bugs im Screensaver, wie wir es vor zwei, drei Jahren mal hatten.

 Oh? Was war denn da?

Es ist mir gerade ein wenig peinlich, dass ich davon nichts weiß...

----------

## cryptosteve

Passend zum Thema gerade frisch eingetrudelt:

http://www.pro-linux.de/news/1/22212/dateisystem-ext4-erhaelt-verschluesselung.html

----------

## Yamakuzure

Oh! Da lohnt es sich für mich ja vielleicht doch mal von ZFS zurück auf ext4 umzusteigen... Mal schauen was das wird...

----------

## Finswimmer

Aber so wie ich das verstanden habe, werden nur die Dateien verschlüsselt.

Metadaten sind nicht verschlüsselt.

Da will ich dann doch lieber eine komplette Verschlüsselung

----------

## schmidicom

Mir ist sowas wie Luks auch lieber, allein schon deswegen weil man dann nicht zur Nutzung eines bestimmten Dateisystem gezwungen wird, aber wenigstens kommt sowas vermutlich auch ohne ein initrd aus was bei LUKS ja spätestens dann nicht mehr der Fall ist wenn "/" ebenfalls verschlüsselt werden soll.

----------

## cryptosteve

Ja, natürlich ist sowas wie LUKS besser. Aber die angedachte ext4-Verschlüsselung sollte ausreichend sein, um sich vor Dateneinsicht bei Diebstahl zu schützen. Außerdem habe ich es so verstanden, dass man diese Art der Verschlüsselung auch im Nachhinein noch initiieren kann, was wiederum ein echter Vorteil wäre.

----------

## Fijoldar

Ich nutze mittlerweile einfach nur die Hardware-Verschlüsselung meiner SSD im Laptop. Der Desktop PC ist gar nicht verschlüsselt. Ebenso mein Server.

----------

## kernelOfTruth

 *Yamakuzure wrote:*   

> 
> 
> Aber aus reiner Neugier: Wie verschlüssel ich ZRAM-Swap? Sollte von der Performance her ja kein Problem sein.
> 
> 

 

ich hab's einfach in die 

/etc/local.d/zram.start

gepackt - danke für den Wink mit dem Zaunpfahl - hatte bis jetzt noch keine Verschlüsselung dafür verwendet   :Rolling Eyes: 

zwar schön umständlich - aber so oft wird das System nicht neugestartet:

```
cryptsetup -y --cipher aes-xts-benbi:sha256 --key-size 512 -h whirlpool luksFormat /dev/zram0

cryptsetup luksOpen /dev/zram0 crypto_ram_swap

mkswap /dev/mapper/crypto_ram_swap

swapon -d /dev/mapper/crypto_ram_swap -p 100
```

----------

## SarahS93

Die von euch die Intel Prozessoren haben und die AES-NI unterstützen. Habt Ihr diese Funktion im Kernel aktiviert oder lasst Ihr das ausschliesslich über die Software machen?

Mal ganz weit und schlimm gedacht .. kann Intel durch seine AES-NI Funktion im Prozessor die verschlüsselung kompromitieren?

----------

## kernelOfTruth

 *SarahS93 wrote:*   

> Die von euch die Intel Prozessoren haben und die AES-NI unterstützen. Habt Ihr diese Funktion im Kernel aktiviert oder lasst Ihr das ausschliesslich über die Software machen?
> 
> Mal ganz weit und schlimm gedacht .. kann Intel durch seine AES-NI Funktion im Prozessor die verschlüsselung kompromitieren?

 

alles ist möglich,

darum verwende ich das z.B. nur für so triviale Sache wie Verschlüsselung der Swap und der System-Partition

ich trau dem ganzen nicht   :Wink: 

Wenn man aber davon schon ausgehen (muss), dann kann man das ganze auch weiterspinnen und

muss die SSSE3-Erweiterungen in die Überlegungen einschließen

Viel Leistung bleibt dann nicht mehr übrig bzw. das meiste muss dann über Software - oder den Prozessor abgearbeitet werden

Im Endeffekt ist es eh wurscht, da man die Daten ja großteils gegen Einbruch, Klau und dergleichen absichert

----------

## Yamakuzure

 *kernelOfTruth wrote:*   

>  *Yamakuzure wrote:*   
> 
> Aber aus reiner Neugier: Wie verschlüssel ich ZRAM-Swap? Sollte von der Performance her ja kein Problem sein.
> 
>  
> ...

 Oha!

Ob man das nicht auch in sys-block/zram-init inbauen könnte?

----------

## forrestfunk81

 *Yamakuzure wrote:*   

>  *forrestfunk81 wrote:*    *Yamakuzure wrote:*   
> 
> Sollte mir jemand das Ding im Laufenden Betrieb klauen und irgend eines der Passwörter, bevor der Akku alle ist oder die Polizei vor der Tür steht, geknackt bekommen, wäre ich wahrscheinlich eher beeindruckt als sauer.  
> 
> Das seh ich auch so. Bei dem Szenario fürchte ich am meisten Bugs im Screensaver, wie wir es vor zwei, drei Jahren mal hatten. Oh? Was war denn da?
> ...

 

2012, Bug in Xorg.

 *Quote:*   

> Basically, an attacker with physical access to an affected computer can bypass the the screensaver / lock screen dialog (GNOME Screensaver, xscreensaver kscreenlocker, etc - on any desktop environment) using a simple keyboard combination, without having to enter the password.

  Kam damals auch über den Heise Ticker, finde es aber gerade nicht mehr.

Ungefähr zur gleichen Zeit gab es auch eine Lücke im Gnome Screensaver (der iirc zum Absturz vom Screensaver führte) und bald darauf noch einen im Unity Screensaver.

----------

## cryptosteve

 *forrestfunk81 wrote:*   

> und bald darauf noch einen im Unity Screensaver.

 

Bugs im (Ubuntu) Screensaver sind keine Seltenheit.

----------

## forrestfunk81

 *cryptosteve wrote:*   

> 
> 
> Bugs im (Ubuntu) Screensaver sind keine Seltenheit.

 

Einer von denen ist schon über ein Jahr alt und immer noch "Unassigned"   :Rolling Eyes: 

Mir fällt noch ein Grund ein Swap zu verschlüsseln: Suspend to disk.

----------

## Yamakuzure

 *forrestfunk81 wrote:*   

>  *cryptosteve wrote:*   
> 
> Bugs im (Ubuntu) Screensaver sind keine Seltenheit. 
> 
> Einer von denen ist schon über ein Jahr alt und immer noch "Unassigned"  
> ...

 Habe ich ausprobiert, ist nichts für mich. Das dauert, auch mit TuxOnIce eeeeeewig. (32GiB RAM)

----------

## katfish

 *Yamakuzure wrote:*   

> ....
> 
> Ich habe zwei Sätze Truecrypt Container.
> 
> Der Erste mit 6 Containern ist für meine diversen Backup Ordner gedacht. Diese synchronisiere ich mit Copy.com. Backups gehen mir also nie verloren, und niemand kann aus der Cloud heraus darauf zugreifen.
> ...

 

Hast Du so viele Platten im Notebook? Anderfalls verstehe ich nicht, weshalb Du die Container so zerstückelst.

----------

## toralf

 *forrestfunk81 wrote:*   

> Mir fällt noch ein Grund ein Swap zu verschlüsseln: Suspend to disk.

 Geht denn das überhaupt zusammen - ich dachte, genau das schließt sich aus.

----------

## Yamakuzure

 *katfish wrote:*   

>  *Yamakuzure wrote:*   ....
> 
> Ich habe zwei Sätze Truecrypt Container.
> 
> Der Erste mit 6 Containern ist für meine diversen Backup Ordner gedacht. Diese synchronisiere ich mit Copy.com. Backups gehen mir also nie verloren, und niemand kann aus der Cloud heraus darauf zugreifen.
> ...

 *lach* nein, ich habe eine Platte. Die Truecrypt Container sind per raidz bzw raidz2 eingebunden, und das hat zwei Gründe:

Backup: Ich synchronisiere meine Backup-Container mit Copy.com. Ohne genau zu wissen wie die Container eingehängt werden, nützt selbst das Cracken einzelner Container nichts. (Ich vertraue Clouds ungefähr soweit wie ich eine Waschmaschine schmeißen kann.)Sicherheit. Einer der Container ist immer Spare. Sollte mir, warum auch immer, mal ein Container kaputt gehen, schmeiße ich ihn raus, der Spare übernimmt, und ich hänge einen neuen Container als neuen Spare ein.Du kannst so viel verschlüsseln, wie du willst. Kaputte Platte ist kaputtePlatte.  :Wink:  Und wenn meine Festplatte abraucht, liegen zumindest meine Backups in der Cloud.

----------

## katfish

Jetzt verstehe ich. 

Ist der Client von Copy.com in der Lage,

beim syncen deiner Container, nur die geänderten Bits zu übertragen? 

Ich nutze owncloud, damit geht das nicht. AFAIK.

----------

## Yamakuzure

 *katfish wrote:*   

> Jetzt verstehe ich. 
> 
> Ist der Client von Copy.com in der Lage,
> 
> beim syncen deiner Container, nur die geänderten Bits zu übertragen? 
> ...

 Jein. Ich denke Dropbox ist da noch etwas effizienter. Aber 20GB auf Copy.com versus 2GB auf DropBox haben mich überzeugt.  :Wink:  Und mit Werbelink gibts immer was oben drauf: https://copy.com/?r=s1C6wm

----------

## Dragonix

Wundert mich, dass hierauf Cold Boot Attack noch keiner eingegangen ist?

In dem Kontext hab ich auch die folgenden Tools erst kennen gelernt, vielleicht kennts jemand noch nicht:

inception: Über Firewire/Thunderbolt mittels DMA auf die unteren 4GB Speicher zugreiffen.

und

volatility: Speicherabbilder verwerten

----------

## Yamakuzure

 *Dragonix wrote:*   

> Wundert mich, dass hierauf Cold Boot Attack noch keiner eingegangen ist?
> 
> In dem Kontext hab ich auch die folgenden Tools erst kennen gelernt, vielleicht kennts jemand noch nicht:
> 
> inception: Über Firewire/Thunderbolt mittels DMA auf die unteren 4GB Speicher zugreiffen.
> ...

 Die Kaltstartattacke ist so dermaßen schwierig erfolgreich umzusetzen, ich glaube als Privatperson muss man sich darum keine großen Gedanken machen.

----------

## xtrace

 *Yamakuzure wrote:*   

> Grundsicherung:
> 
> -------------------
> 
> Drei unterschiedliche Passwörter für das Einschalten, das BIOS, sowie den Festplattencontroller und die Festplatte.
> ...

 

Hallo, Yamakuzure!

Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.

Hast du nach einem Howto gearbeitet? Kannst du mir ein Howto empfehlen? 

Ich bedanke mich im Vorraus.

cu,

xtrace

----------

## katfish

cold boot - als es damals public wurde, 

dachte ich darüber nach, meinen speicher festzukleben. 

bisher beschränke ich mich aber darauf, an meinem notebook,  

das booten von anderen medien nur mit bios pw zu erlauben. 

Als AES NI rauskam, dachte ich, das dadurch cold boot attacken nicht mehr möglich sind -

das ist aber nicht sicher. auf der Luks ML gab es mal eine diskussion dazu, aber keinen konsens.

----------

## katfish

 *Quote:*   

> 
> 
> Hallo, Yamakuzure!
> 
> Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.
> ...

 

https://wiki.gentoo.org/wiki/DM-Crypt_LUKS

----------

## cryptosteve

 *katfish wrote:*   

> https://wiki.gentoo.org/wiki/DM-Crypt_LUKS

 

Er hat aber gar kein LUKS, sondern TrueCrypt. Oder hab ich den entscheidenen Part übersehen/-lesen?

----------

## xtrace

 *katfish wrote:*   

>  *Quote:*   
> 
> Hallo, Yamakuzure!
> 
> Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.
> ...

 

so habe ich es im Moment eingerichtet.

Das ist allerdings eine ganz andere Art und Weise, als es Yamakuzure gelöst hat.

 *cryptosteve wrote:*   

>  *katfish wrote:*   https://wiki.gentoo.org/wiki/DM-Crypt_LUKS 
> 
> Er hat aber gar kein LUKS, sondern TrueCrypt. Oder hab ich den entscheidenen Part übersehen/-lesen?

 

Nein. Richtig. Er nutzt Truecrypt.

----------

## Yamakuzure

 *xtrace wrote:*   

> Hallo, Yamakuzure!
> 
> Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.
> 
> Hast du nach einem Howto gearbeitet? Kannst du mir ein Howto empfehlen? 
> ...

 Nein, kein Howto. Wenn du die Container erstellt und mit TrueCrypt "gestartet" hast (Ohne mount, also mit --filesystem=none), kannst du die Laufwerke aus /dev/mapper wie gewöhnliche laufwerke per zpool in raidz1 oder raidz2 zusammenfassen.

Siehe:

```
 ~ # zpool list -v

NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT

bpool  4,97G  3,55G  1,42G         -    41%    71%  1.00x  ONLINE  -

  raidz1  4,97G  3,55G  1,42G         -    41%    71%

    truecrypt21      -      -      -         -      -      -

    truecrypt22      -      -      -         -      -      -

    truecrypt24      -      -      -         -      -      -

    truecrypt25      -      -      -         -      -      -

    truecrypt26      -      -      -         -      -      -

gpool   318G   183G   135G         -    36%    57%  1.00x  ONLINE  -

  sda4   318G   183G   135G         -    36%    57%

ppool  69,5G  43,1G  26,4G         -    29%    61%  1.00x  ONLINE  -

  raidz2  69,5G  43,1G  26,4G         -    29%    61%

    truecrypt11      -      -      -         -      -      -

    truecrypt12      -      -      -         -      -      -

    truecrypt13      -      -      -         -      -      -

    truecrypt14      -      -      -         -      -      -

    truecrypt15      -      -      -         -      -      -

    truecrypt16      -      -      -         -      -      -

    truecrypt17      -      -      -         -      -      -

 ~ # zpool status ppool

  pool: ppool

 state: ONLINE

  scan: scrub repaired 0 in 0h18m with 0 errors on Fri Sep 19 21:02:37 2014

config:

        NAME             STATE     READ WRITE CKSUM

        ppool            ONLINE       0     0     0

          raidz2-0       ONLINE       0     0     0

            truecrypt11  ONLINE       0     0     0

            truecrypt12  ONLINE       0     0     0

            truecrypt13  ONLINE       0     0     0

            truecrypt14  ONLINE       0     0     0

            truecrypt15  ONLINE       0     0     0

            truecrypt16  ONLINE       0     0     0

            truecrypt17  ONLINE       0     0     0

        spares

          truecrypt18    AVAIL   

errors: No known data errors

 ~ # zpool status bpool

  pool: bpool

 state: ONLINE

  scan: scrub repaired 0 in 0h1m with 0 errors on Fri Sep 19 20:43:31 2014

config:

        NAME             STATE     READ WRITE CKSUM

        bpool            ONLINE       0     0     0

          raidz1-0       ONLINE       0     0     0

            truecrypt21  ONLINE       0     0     0

            truecrypt22  ONLINE       0     0     0

            truecrypt24  ONLINE       0     0     0

            truecrypt25  ONLINE       0     0     0

            truecrypt26  ONLINE       0     0     0

        spares

          truecrypt23    AVAIL   

errors: No known data errors
```

Ich würde allerdings empfehlen ein Script zu schreiben, dass das Einhängen nach jedem Boot übernimmt.

Das Skript sollte die Pools erst einmal exportieren, *bevor* die Container eingehängt werden, und erst dann importieren. Das Zusammenbauen der Raids übernimmt zpool dann ganz von alleine.

Achja: Feste Slots vergeben!

So sieht das Skript bei mir aus:

```
#!/bin/bash

pw=""

# Disable history expansion on exclamation marks

set +H

if [ $# -ne 2 ] ; then

        read -sp "PW ? " pw

else

        pw="${1}"

fi

echo "Clearing pools"

sudo zpool export bpool

sudo zpool export ppool

xOpts="-t --filesystem=none --keyfiles= --volume-type=normal --protect-hidden=no --password=${pw}"

# private :

echo -n "Mounting containers for ppool ..."

for nr in $(seq 1 8) ; do

        truecrypt $xOpts --slot=1${nr} /Pfad/zum/ppool/ppool_${nr}.7z

done

echo " done"

# backup :

echo -n "Mounting containers for bpool ..."

for nr in $(seq 1 6) ; do

        truecrypt $xOpts --slot=2${nr} /Pfad/zum/bpool/bpool_${nr}6.7z

done

echo " done"

# Starte pools

echo -n "Mounting ppool ..."

sudo zpool import -f ppool

echo " done"

echo -n "Mounting bpool ..."

sudo zpool import -f bpool

echo " done"
```

(Ich habe die Pfade ein wenig retuschiert.  :Wink:  )

Schwachpunkt: Alle Container verwenden das selbe Passwort. Sobald ich mal Zeit habe, werden ich allen ungeraden Containern ein anderes Passwort geben.

----------

## katfish

 *Quote:*   

> 
> 
> Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.
> 
> Hast du nach einem Howto gearbeitet? Kannst du mir ein Howto empfehlen? 
> ...

  *Quote:*   

> 
> 
> https://wiki.gentoo.org/wiki/DM-Crypt_LUKS

 

xtrace,

Sorry, ich dachte, Du nutzt noch gar keine Verschluesselung. 

An deiner Stelle würde ich Truecrypt meiden, da es nicht mehr weiterentwickelt wird.

AFAIK ist Luks/DM-Crypt auch nicht schlechter als Truecrypt. Mit containern kann es auch umgehen.

----------

## Yamakuzure

 *katfish wrote:*   

>  *Quote:*   
> 
> Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.
> 
> Hast du nach einem Howto gearbeitet? Kannst du mir ein Howto empfehlen? 
> ...

 Naja, Truecrypt hat sein letztes Release schon vor Jahren gesehen, es gibt schlicht nichts weiterzuentwickeln. Vielleicht haben die Entwickler auch deswegen Schluss gemacht? Wer weiß?

Aber es gibt ja auch schon NAchfolgeprojekte, wie z.B. VeraCrypt. Nur werden alle Nachfolger irgendwann TrueCrypt ersetzen, aber kaum was "draufpacken" können. Fertig ist fertig.

Wie dem au sein, nach eingehenden Prüfungen, zum Beispiel vom Open Crypto Audit Project, soll TrueCrypt ja weitestgehend sicher sein.

----------

## SkaaliaN

Ich habe auch lange Truecrypt eingesetzt und war eigentlich zufrieden.

Ich bin dann allerdings vor einiger Zeit auf LUKS gewechselt. Bisher keine Probleme gehabt.

Unter anderem deswegen:

http://www.pcwelt.de/news/Truecrypt_ist_angeblich_unsicher___Entwicklung_eingestellt-Unsichere_Verschluesselung-8743009.html

Dort steht u.a.: 

 *Quote:*   

> 
> 
> Es kursiert allerdings auch die Vermutung, dass es den US-Geheimdiensten gelungen sei, Truecrypt zu kompromittieren. Ein ähnlicher Verdacht schwebt seit einiger Zeit auch über dem Verschlüsselungsnetzwerk von Tor. 

 

Ob was an der Sache dran ist!? Keine Ahnung. Komisch war die ganze Aktion schon..

Die US Geheimdienste sind mir eigentlich auch egal. Es geht sich um das Prinzip. Ob die bekannten Türchen auch ausschließlich bei ihnen bleiben, dass ist die andere Sache. 

Das schweift nun aber zu sehr vom Thema ab.

----------

## katfish

Yamakuzure,

ich hab den Wirbel um TC auch verfolgt,

und behaupte auch nicht, dass es unsicher ist  :Wink: 

Weshalb setzt Du denn auf TC?

----------

## xtrace

 *Yamakuzure wrote:*   

>  *xtrace wrote:*   Hallo, Yamakuzure!
> 
> Deine Maßnahmen i.S. Verschlüsselung hören sich sehr interessant an und ich würde dies gerne auch so umsetzen.
> 
> Hast du nach einem Howto gearbeitet? Kannst du mir ein Howto empfehlen? 
> ...

 

Hallo, Yamakuzure!

Ich werde es testen. Danke. Hört sich sehr komplex an  :Smile:  Ich bin gespannt.

----------

## Yamakuzure

 *katfish wrote:*   

> Yamakuzure,
> 
> ich hab den Wirbel um TC auch verfolgt,
> 
> und behaupte auch nicht, dass es unsicher ist 
> ...

 Container und Cross-Platform-Kompatibilität.

Du kannst mit LUKS keinen Container unter Linux erstellen, Daten rein tun, den Container auf eine externe Festplatte kopieren, und den Container unter Windows mounten.

----------

## py-ro

@Yamakuzure doch das geht mit LUKS, gibt entsprechende Implementierung für Windows.

----------

## Yamakuzure

 *py-ro wrote:*   

> @Yamakuzure doch das geht mit LUKS, gibt entsprechende Implementierung für Windows.

 

Oh? das wusste ich noch garnicht. Wieder etwas gelernt.

So, hab mal etwas nachgelesen, und *nope*, wir bleiben wohl bei Truecrypt. Die Alternative auf Windows (FreeOTFE für LUKS-Container) sind noch nicht so das Wahre.

FreeOTFE: Wird seit 3-4 Jahren nicht weiterentwickelt (freeotfe.org ist tot, die neueste Version auf SourceForge ist vom 04.01.2012)

VeraCrypt soll unglaublich langsam sein (unbestätigt)

DiskCryptor ist inkompatibel zu allem über Windows 7 und soll schon manchen MBR geschrottet haben   :Shocked: 

Oh, nochwas gefunden: Alternativen zu TrueCrypt

Also eine echte Alternative gegenüber dem (geprüften!) TrueCrypt tut sich da noch nicht auf.

Aber ich hoffe, es taucht irgendwann eine Alternative auf.

----------

## furanku

Ich habe mittlerweile gar nichts mehr verschlüsselt. Ich kenne mich zwar so einigermaßen mit Rechnern und Sicherheit als Informatik-Nebenfächler aus. Da liegt aber die Crux: Ich weiss 

 mittlerweile genug, um zu wissen, dass ich nicht genug weiss, um meine Verschlüsselungen wirklich wasserdicht zu machen,

 dass wirkliche Datensicherheit mehr ist als ein HOWTO zur Plattenverschlüsselung nachzuvollziehen und

 dann der Nutzungskomfort und die Nutzungsmöglichkeiten ganz erheblich eingeschränkt sind und das eine hohe Disziplin erfordert.

Nehmt das bitte nicht als Angriff auf eure Sicherheitskonzepte, aber ich befürchte, dass "gefühlte" Sicherheit schlimmer ist als gar keine.

----------

## mv

 *furanku wrote:*   

> Ich habe mittlerweile gar nichts mehr verschlüsselt. [...]
> 
> Nehmt das bitte nicht als Angriff auf eure Sicherheitskonzepte, aber ich befürchte, dass "gefühlte" Sicherheit schlimmer ist als gar keine.

 

Man muss sich im Klaren sein, was man mit Festplattenverschlüsselung erreicht, und darf nicht mehr (aber auch nicht weniger) erwarten:

Man erhält einen Schutz gegen einmaligen "offenen" physikalischen Zugriff auf den Rechner.

Wenn man also befürchtet, dass einem jemand auf Reisen den Laptop stiehlt, und dann damit Unfug angestellt wird, ist das schon sehr nützlich; und für diesen Schutz genügt auch ein einfaches HOWTO aus dem Netz.

Wenn man hingegen erwartet, auch beliebig im Netz surfen zu können, ohne um seine Daten fürchten zu müssen, nur weil die Festplatte verschlüsselt ist, macht man den bekannten Fehler der Überkompensation.

Gegen heimlichen physikalischen Zugriff hilft Verschlüsselung auch nicht, weil Trojaner oder Hardware-Keylogger heutzutage für entsprechende Organisationen sogar schneller zu realisieren sind, als eine Kopie der Festplatte zu ziehen.

----------

## furanku

Dem kann ich einigermaßen zustimmen. Ich wollte betonen, dass Sicherheit immer ein Konzept ist und man selber Teil dieses Konzepts ist. Man sollte schon wissen, was man genau wogegen eigentlich schützen will -- und was man dann verantwortungsvollerweise überhaupt noch mit seinem Rechner machen kann, ohne mit dem Arsch einzureißen was man mit den Händen aufgebaut hat. Das genannte Nachvollziehen eines HOWTOs zur Plattenverschlüsselung hilft z.B. beim Diebstahl des Laptops, wenn der Dieb nicht selber Experte auf dem Thema ist und wiederum Angriffe auf die Verschlüsselung kennt -- und überhaupt an den Daten interessiert ist und den Laptop nicht einfach schnell beim Hehler verkaufen will. Und dann stellt sich eben die Frage: Welche Daten sind sicherheitsrelevant? Die eigene Porno-Sammlung? Nö, sicher nicht. Onlinebanking-Logindaten? Sollte man die besser nicht auswendig lernen als sie dem Passwortspeicher eines Browsers anzuvertrauen (dann zahlt die Bank bei Missbrauch auch nicht, egal ob die Platte verschlüsselt war)? Usw. ...

Ich bin da für mich zum Schluss gekommen, dass Festplattenverschlüsselung nicht notwendig ist. Your Mileage may vary. Wenn ich allerdings in Foren solche Diskussionen mitlese überkommt mich aber leider manchmal das Gefühl, dass einige da sowohl ihr Verständnis der krytologischen Verfahren als auch die Kenntniss deren konkreter Implementation überschätzen und sich dann in einer trügerischen gefühlten Sicherheit gerade zu riskantem Verhalten hinreissen lassen.

----------

## Fijoldar

Wobei man das ganze auch nicht zu schwarz malen sollte. Eine Festplatte mit Hilfe von Luks/LVM zu verschlüsseln, ist nicht wirklich schwer. Wenn man darauf achtet, eine entsprechend starke Verschlüsselungsmethode zu verwenden und natürlich ein sicheres(!) Passwort wählt, hat man eine ausreichend gute Verschlüsselung, die selbst Experten nicht so leicht knacken.

Dass es natürlich wenig bringt, wenn man zu Hause seinen Desktop PC voll verschlüsselt, wenn neben im Regal die Aktenordner mit sensiblen Daten stehen, ist natürlich eine andere Sache  :Smile: . Das meinst du vermutlich mit "Konzept". Bei einem Laptop würde ich es aber immer machen.

----------

## Finswimmer

Zum Thema "sicherer Schlüssel": 512 Byte random Schlüssel nehmen, das als Datei speichern und per GPG mit einem "normal" starken Passwort verschlüsseln.

Die Datei dann auf einen USB-Stick. Und da ich nur ~ 1x Monat den Rechner neustarte, ist das alles sogar sehr bequem.

----------

## furanku

Da bin ich mir nicht sicher, ob das wirklich sicherer ist. Im Allgemeinen ist so eine Kette an Sicherungsmaßnahmen nur (höchstens) so sicher wie das schwächste Glied. Um an Deine Daten zu kommen braucht man nun zwar zusätzlich den USB-Stick, dafür dann aber nur noch das "normal starke Passwort". Zusätzlich hast Du Dir aber eine ganze Reihe an neuen potentiellen Schwachstellen eingefangen: Nun ist die korrekte Funktionsweise von GPG gefordert, das ganze USB-Subsystem hängt an kritischer Stelle in Deinem Sicherheitskonzept, wer Dich beobachtet, weiß, dass er Dir nur mal kurz den USB-Stick klauen muss (und unauffällig zurücklegen muss) statt längerfristigen Zugang zu deinem Rechner zu haben, um mit der Attacke zu beginnen, usw. ...

Ich weiß, das sind alles unwahrscheinliche Szenarien, aber mir geht es hier darum, dass das "Hintereinanderschalten" von Sicherheitskonzepten oft die Sicherheit verschlechtert: Man vergrößert die Anzahl der möglichen Angriffe und die ganze Kette ist nur so stark wie das schwächste Glied. Die beste Sicherheit basiert oft auf einfachen aber strengen und leider eben unbequemen Konzepten; komplizierter oder komfortabler bedeutet meist auch unsicherer.

----------

## Dorsai!

 *furanku wrote:*   

> Ich weiß, das sind alles unwahrscheinliche Szenarien, aber mir geht es hier darum, dass das "Hintereinanderschalten" von Sicherheitskonzepten oft die Sicherheit verschlechtert: Man vergrößert die Anzahl der möglichen Angriffe und die ganze Kette ist nur so stark wie das schwächste Glied. Die beste Sicherheit basiert oft auf einfachen aber strengen und leider eben unbequemen Konzepten; komplizierter oder komfortabler bedeutet meist auch unsicherer.

 

Eigentlich nicht. GPG-verschlüsselte Keyfiles sind sowohl eine durchaus gebräuchliche Maßnahme und z.B. die beste Maßnahme die mir einfällt um mehrere Volumes mit nur einer Passworteingabe zu entschlüsseln.

Das USB abzuhören kann man sich eigentlich schenken, da über USB nur verschlüsselte Daten übertragen werden, bzw. auf dem USB-Stick liegen.

Natürlich, wenn einer die GPG Verschlüsselung (mathematisch) knackt, dann ist hopfen und Malz verloren, aber so lange ist die Kette nicht so stark wie ihr schwächstes Glied, sondern ihr erstes Glied.

Und zum Hintereinanderschalten: Fast alle Kryptographischen Systeme für Endnutzer verwenden ein Hintereinanderschalten von verschiedenen Maßnahmen. Zum Beispiel bei LUKS wird nicht das Passphrase was du eingibst direkt als Key für die Platte genommen. Das wird zuerst gesalzen, dann durch PBKDF2 einen Keystretchingalgorithmus (wie ein zig tausend mal wiederholter hash) gejagt, dann wird der starke, aus Zufallsdaten generierte tatsächliche Key damit verschlüsselt und im Header abgespeichert. LUKS wird durch dieses vorgehen nur viel sicherer, da ein Angreifer praktisch die Wahl hat dazwischen binär alle Keys auszuprobieren (was mit normalen Computern undenkbar ist) oder die Passphrase zu bruteforcen (was länger dauert je mehr schritte man hintereinander schaltet).

Die beschriebene GPG Methode verwendet im Prinzip das aller selbe Verfahren nochmal was dich als Angreifer wieder zusätzlich Zeit kostet. Schwachstellen im Algorithmus oder der Implementierung mal weggelassen verlierst du dadurch also nicht an Sicherheit sondern gewinnst sogar theoretisch noch.

Ganz wichtig ist dabei natürlich, dass man keine Anwenderfehler macht und die Klartext Keys z.B. irgendwie auf die Festplatte oder den USB-Stick schreibt. Selbst wenn die Daten im Dateisystem "gelöscht" sind lassen sie sich unter Umständen wieder rekonstruieren.

----------

## furanku

OK, einerseits hast Du in diesem Fall Recht, andererseits kannst Du nichts gegen "Komfort kann zusätzliche Angriffe möglich machen" sgen. Je komplexer das Verfahren desto mehr mögliche Schwachstellen gibt es 

 beim Algorithmus selber

 in der Implementation

 durch externe Quellen (z.B. fehlerhafter Zufallszahlengenrator)

 in der fehlerhaften Konfiguration durch den Nutzer

 durch "Side-Channel"-Angriffe, wie z.B. den die elektrische Leistung der CPU oder das Timing der Speicherzugriffe

Auch wenn das teileweise unwahrscheinliche Angriffe sind, ändert das nichts an den Prinzipien: Komplexität macht angreifbar, ein 512-Byte Schlüssel ist sicherer als ein "normal sicheres Passwort".

Da Du mit der Zeit für einen Brute-Force Angriff argumentierst: Das müsste man erst mal statistisch genauer untersuchen: Natürlich ist ein Verfahren, dass ein "1-Bit Passwort", dass jedoch durch zimilliarden Iterationen jagt, weder theoretisch sicher noch praktisch nutzbar. Wie der "Sicherheitsverlauf" zwischen diesen Extremen ist, ist schwer abzuschätzen. Du postuliertst, dass es da ein Maximum gäbe ("man gewinnt Sicherheit"), aber das ist eben nur "geschätzt".

Da kämen dann z.B. wieder Tabellen-basierte Angriffe u.ä. ins Spiel. OK, dann wird gesalzen, aber damit holst Du Dir eben nach oben genanntem wieder neue mögliche Angriffe ins Bild, usw. Letztlich ist die Sicherheit dann nur noch durch grobe Abschätzungen unter gewagten Voraussetzungen beurteilbar (Du selber schreibst "Schwachstellen im Algorithmus oder der Implementierung mal weggelassen"). Diese Schwachstellen gibt es aber doch durchaus -- und auch da: Je komplexer desto wharscheinlicher doch irgendwo fehlerhaft oder angreifbar.

Dann kann man schon, wenn man kritisch ist, anführen, dass das eine "gefühlte" Sicherheit ist, im Glauben an Algorithmen die man nicht verstanden hat (und die durchaus Fehler haben können), Implementationen, die man nicht nachvollzogen hat (und die tatsächlch Bugs enthalten), Konfigurationen, die man einfach übernommen hat und Konzepten, die möglicherweise in sich nicht durchdacht sind (z.B. das von Dir gennante unsichere Löschen des Klartext-Passwort in ungeschützen Bereichen oder Schlimmeres: In sicherheitsrelavanten Unternehmensbereichen ist z.B. der von dir benutzte USB-Stick selber schon lange verboten)

Ganz allgemein sollte die lange und trauriger Liste bekannter katastrophaler Sicherheitslücken der letzten Jahre uns etwas bescheidener machen: Die Komplexität ist selbst den Experten offensichtlich schon über den Kopf gewachsen.

Ich mag es pessimistisch sehen, aber ich glaube eben, dass für Endbenutzer die Konsequenz ein sicherheitsbewusster Umgang mit den eigenen Daten und ein Drängen auf politische und gesetzliche Lösungen sein muss, nicht die Flucht in "laubgesägte" eigene hochkomplexe Sicherheitskonzepte, die man selber nicht mehr durchschaut -- sich dabei aber in falscher Sicherheit wiegt.

Um noch mal etwas versöhnlicher zu werden hier mal ein Beispiel für einen Side-Chain-Angriff aus meiner Erfahrung: Ich habe lange meine Passworte nach der Methode "Anfangsbuchstaben von Songtexten mit ein enig Zahlen und Sonderzeichen erweitert" gemacht ... Bis ich mich dann selber erwischte wie ich das entsprechende Lied bei der Passworteingabe mitsummte.  :Wink: 

----------

