трънки и блогинки

Cryptsetup във Fedora и въпрос

Написано на: 13.03.2007 · 5 коментара

Мариян е написал за създаването на криптирани сектори с cryptoloop, а аз искам да го допълня с инструкции за cryptsetup, който идва с Fedora и ще замени cryptoloop. Примерът ползва LUKS допълнението на cryptsetup, заради възможностите за автоматизация и ползване на ключове:

1. Създаване на файл, който ще държи данните
dd if=/dev/urandom of=/home/$USER/encrypted bs=1M count=10
2. Асоциираме loop устройството с файла
losetup /dev/loop0 /home/$USER/encrypted
3.1 Създаваме криптиранo устройство
cryptsetup -y luksFormat /dev/loop0
3.2 Отваряме до за достъп
cryptsetup luksOpen /dev/loop0 encrypted

3.3 Създаваме ext3 файлова система
mke2fs -j /dev/mapper/encrypted
4.1. Създаваме точка на монтиране
mkdir /mnt/encrypted
4.2. и го монтираме там
mount /dev/mapper/encrypted /mnt/encrypted
5. Правим, каквото правим.
6. И си излизаме като свършим
umount /mnt/encrypted
cryptsetup luksClose encrypted

За ежедневна употреба изпълняваме само точки 2, 3.2, 4.2, 5 и 6, като разбира се може и да ги автоматизираме. Истинската благина за потребителя ще настане с интеграцията с HAL, за която LUKS създава условия и управлението ѝ с инструменти като gnome-luks-format. Може да прочетете и още за cryptsetup и luks.

Въпреки възможността за създаване на криптирани дялове, аз се чудя дали има начин в зависимост от паролата да изпълня някакво действие върху криптираните дани. Примерно да бъдат заличавани при въвеждане на определена парола или да се показва само част от тях и други подобни мерки в случай, че бъде оказан натиск върху администриращия данните. Не може някой да не се е сетил преди мен, нали?

Категория: свободни неща

5 коментара ↓

  • Хубаво ми е, когато хората коментират. Чета внимателно всеки коментар и отговарям, когато имам какво да кажа.

  • valntine на 14.03.2007г. в 00:29ч.

    >> Примерно да бъдат заличавани

    Сетих се за това като прочетох Cryptoloop-HOWTO за първи път но не се бях замислял.

    Според мен не е никак трудно да се имплементира колкото и семпло да звучи предложението ми.

    Идеята е следната:

    1. Прави се един user land tool подобен на горе-споменатия (c, c++, perl, php, etc) който да автоматизира 2, 3.2 и 4 за ежедневна употреба.

    2. В инструмента се добавят още 2 пароли криптирани с алгоритъм по избор (за предпочитане blowfish:)

    – if(pass = bad_hash)
    shred -f -n100000 -u /path/to/my/crypto/container
    – if(pass = right_hash)
    proceed to 2, 3.2, 4
    – else = get the hell out of here exit(0)

    Мерси че ме накара да се замисля :) Горното отива в TODO листата.

    Поздрави.

  • valntine на 14.03.2007г. в 00:41ч.

    И още нещо :) Kъм горе-споменатия инструмент може да се добави още едно ниво на защита:

    Binary Protection Schemes by Andrew Griffiths:

    http://2005.recon.cx/recon2005/papers/Andrew_Griffiths/

  • Христо Еринин на 14.03.2007г. в 13:06ч.

    Аз използвам EncFS (http://arg0.net/encfs), който пък използва FUSE (Filesystem in USErspace). Има си предимства пред loop, има и недостатъци – http://arg0.net/wiki/encfs/intro2
    С други думи на всеки според нуждите, от всеки според възможностите. ;-)
    По твоята чуденка съм си мислел и аз. Единственият вариант е, това да бъде реализирано от самия crypto алгоритъм. Всичко, което реализираш client-side става безмислено в момента, в който си зададеш въпроса „А този готин и ерудиран човек, който знае толкова много начини да причинява болка и толкова умело ми демонстрира болка, която не съм и подозирал, че може да съществуват, защо, аджеба ще използва моите client-side програми, вместо неговите си?“ ;-)
    Приемаме, че не работим с черна crypto кутия, нали така?
    Security through obscurity не става, но без obscurity не може ;-))

  • пейо на 14.03.2007г. в 14:53ч.

    Забравих да кажа, че във всички учебници по криминалистика се подчертава възможно най-дебело да се ползват недеструктивни методи. Това специално за данните означава винаги да се работи на тяхно копие, което прави триенето не толкова ефективно.

    @ valntine
    Моля обади се като имаш някаква конкретна идея, защото аз колкото мисля толкова само повече проблеми намирам.

    @ Еринин
    Може би не в самия алгоритъм, а по-скоро в програмната му реализация. Имам предвид, че алгоритъма ще преобразува данните винаги, но идентичността на оригиналните данни се проверява чрез хеш. Може би точно при тази проверка би било уместно, но е глупаво сам да си приказвам така, като съм сигурен, че някой по-знаещ вече е мислил и писал по въпроса.

  • Alexx на 07.05.2007г. в 01:29ч.

    от помощната страница на EncFS:
    –anykey
    Turn off key validation checking. This allows EncFS to be used with secondary passwords. This could be used to store a separate set of files in an encrypted filesystem. EncFS ignores files which do not decode properly, so files created with separate passwords will only be visible when the filesystem is mounted with their associated password.

    Т.е. би трябвало да е възможно съхраняването на дадени файлове с обща парола и съхраняването на „други“ файлове с тайна парола. Не съм го пробвал.