# smartcard + dm-crypt-luks + encrypted filesystem

## redgsturbo

Has anyone tried an encrypted filesystem with luks using a smartcard protected key for the partitions?  If not I am going to make a go of it with some good old trial and error.  If anyone has any knowledge in this area I'd love to hear it.  My motivation is a work supplied laptop + corporate encrypted file system requirements + DoD CAC (going to purchase my own smartcard to try first... don't want to rely on others to unlock a locked card).

----------

## manaka

AFAIK, cryptsetup/LUKS don't seem to fit very well... cryptsetup/LUKS needs a passphrase in order to decrypt a copy of the master key stored in the LUKS header (this process is rather convoluted).

Smartcards/tokens are typically designed to not disclose sensitive data... The just perform operations like signing/decrypting using their engine and the internal private keys...

I don't see a clear way to integrate both worlds...

You can always use cryptsetup/LUKS the normal way (typing the passphrase)... The process is very secure... And works very well in Gentoo... You can even encrypt the root filesystem if the initramfs includes LUKS support...  :Smile: 

Cheers.

Javi.

----------

## redgsturbo

 *manaka wrote:*   

> AFAIK, cryptsetup/LUKS don't seem to fit very well... cryptsetup/LUKS needs a passphrase in order to decrypt a copy of the master key stored in the LUKS header (this process is rather convoluted).
> 
> Smartcards/tokens are typically designed to not disclose sensitive data... The just perform operations like signing/decrypting using their engine and the internal private keys...
> 
> I don't see a clear way to integrate both worlds...
> ...

 

You can use a passphrase, or a GPG key, or both in LUKS... using a GPG key is better than a passphrase, but then the GPG key still must be protected with a passphrass... suppose that GPG was stored on the smartcard, or merely encrypted/decrypted by the smart card, it would be far safer as it would prevent bruteforce attacks.  I'm positive it can be done... and has been done on cryptsetup.  The LUKS adds the ability to have multiple keys (so a broken or stolen smartcard doesn't totally hose your system).

----------

## redgsturbo

Just thought I'd update

After countless reboots and some script re-writing I have the AES root and swap crypto working loosly based on http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS.  The smartcard should be at my house today, and I've already started working on adding the smartcard support to the init script.  Anyone interested in this?  (Interested enough for me to update the wiki entry and include smartcard support?)

----------

## episch

I'm definitely interested. Keep up the good work  :Smile: 

----------

## fallen

Yeah, i'm also very interested.

What kind of smartcard did you purchase?

----------

## redgsturbo

 *fallen wrote:*   

> Yeah, i'm also very interested.
> 
> What kind of smartcard did you purchase?

 

Axalto Cryptoflex E-Gate 32K Card + Axalto Cryptoflex E-Gate and Reflex 531 USB (so I can use a card in my laptop, and the same card in my rackmount machines that have front usb access... the chip pops out and fits into a thumbdrive style usbstick)

----------

## fallen

How much did that run you?

----------

## redgsturbo

 *fallen wrote:*   

> How much did that run you?

 

$40?  Individual cards are about $15

----------

## manaka

In my last message I didn't explain things very well... I was meaning it would be rather convoluted... As you would have to do something like this...

1) You read an encrypted key stored in a filesystem (you can't read it from the smartcard. AFAIK, they don't store data like a flash device).

2) The key is decrypted by the smartcard using one of its private keys (pkcs15-crypt --decipher).

3) The key is passed to cryptsetup (cryptsetup --key-file).

4) cryptsetup/luks uses the former key to decrypt a copy of the master key stored in one of the 8 slots.

In any case, I would be interested in hearing about your work in this area...  :Smile: 

Cheers.

Javier Miqueleiz.

----------

## redgsturbo

 *manaka wrote:*   

> In my last message I didn't explain things very well... I was meaning it would be rather convoluted... As you would have to do something like this...
> 
> 1) You read an encrypted key stored in a filesystem (you can't read it from the smartcard. AFAIK, they don't store data like a flash device).
> 
> 2) The key is decrypted by the smartcard using one of its private keys (pkcs15-crypt --decipher).
> ...

 

I'm either doing that, or storing the key directly on the card (this is possible.. the card has 32k of space and capable of importing keys).  I'm having trouble getting the public key off the card with pkcs15 tools.  It always complains about "out of memory" but it shouldn't be complaining about this.  There is a pkcs15-crypt --decipher, but no encryption so I have to get that pub key to encrypt the key in the first place... failing that I will just put my own key on there but I like the idea of the secret key existing only on the card.,  Any ideas?

----------

## XAvAX

I'm very interested in this as well. While looking for similar data, I came across https://systemausfall.org/mail-archive/?0::240 - It seems that this person has already implemented what you need. For those using genkernel, since so far as I know it copies all of /boot, /lib, /bin and /etc into the initrd unchanged, all that would be needed would be copying the files to the necessary locations and some trivial patching of /usr/share/genkernel/generic/linuxrc. I'll try it in the morning, since it's midnight:40 local time. If it works, I'll post a diff of linuxrc and where to put the files.

UPDATE: 8/26/07: I have ebuilds that install the neccessary files and provide instructions on how to set up the initrd generation scripts that genkernel uses in order to have them work with the utilities. I do not currently own a smartcard reader, so these apps are UNTESTED by me. The writer of these scripts reports success, here are the ebuilds:

Update again: Gah, the script that is supposed to copy the smartcard binaries isn't working. If anyone's willing to patch it, I'd be grateful, but it seems to have been written for Debian.

=sys-apps/initramfs-tools-0.90a.ebuild

```
# Copyright 1999-2007 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/sys-apps/debianutils/debianutils-2.22.1.ebuild,v 1.5 2007/08/17 01:26:44 vapier Exp $

inherit eutils flag-o-matic

DESCRIPTION="A set of tools for creating initramfs images from Debian"

HOMEPAGE="http://packages.debian.org/unstable/utils/${PN}"

SRC_URI="mirror://debian/pool/main/i/${PN}/${PN}_${PV}.tar.gz"

LICENSE="GPL-2 BSD"

SLOT="0"

KEYWORDS="~x86"

IUSE=""

RDEPEND="app-arch/cpio

   >=dev-libs/klibc-1.4

   >=sys-apps/busybox-1.1

   sys-apps/module-init-tools

   >=sys-fs/udev-100"

DEPEND="${RDEPEND}"

src_unpack() {

   unpack ${A}

   S="${WORKDIR}/${PN}"

   cd "${S}"

}

src_install() {

   S="${WORKDIR}/${PN}"

   cd ${S}

   

   dodir /usr/share/initramfs-tools/modules.d

   dodir /var/lib/initramfs-tools

   dodir /etc/initramfs-tools

   dodir /etc/initramfs-tools/conf.d

   dodir /etc/initramfs-tools/hooks

   dodir /etc/initramfs-tools/scripts

   dodir /etc/initramfs-tools/scripts/init-bottom

   dodir /etc/initramfs-tools/scripts/init-premount

   dodir /etc/initramfs-tools/scripts/init-top

   dodir /etc/initramfs-tools/scripts/local-bottom

   dodir /etc/initramfs-tools/scripts/local-premount

   dodir /etc/initramfs-tools/scripts/local-top

   dodir /etc/initramfs-tools/scripts/nfs-bottom

   dodir /etc/initramfs-tools/scripts/nfs-premount

   dodir /etc/initramfs-tools/scripts/nfs-top

   insinto /etc/initramfs-tools/

   newins conf/initramfs.conf initramfs.conf

   newins conf/update-initramfs.conf update-initramfs.conf

   newins conf/modules modules

   exeinto /usr/share/bug/initramfs-tools

   newexe debian/script script

   insinto /usr/share/initramfs-tools

   newins conf/modules modules

   doins hooks

   doins scripts

   exeinto /usr/share/initramfs-tools

   doexe hook-functions

   doexe init

   insinto /usr/share/initramfs-tools/examples

   newins conf/modules modules

   exeinto /usr/share/initramfs-tools/examples

   newexe docs/example_script example_script

   newexe docs/example_hook example_hook

   newexe docs/example_hook_cpiogz example_hook_cpiogz

   into /usr

   dosbin mkinitramfs mkinitramfs-kpkg update-initramfs

   dodoc HACKING

   doman mkinitramfs.8 mkinitramfs-kpkg.8 initramfs.conf.5 initramfs-tools.8 update-initramfs.8 update-initramfs.conf.5

}

```

=app-crypt/cryptsetup-opensc-0.1.ebuild

```
# Copyright 1999-2007 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/x11-themes/smooth-themes/smooth-themes-0.5.8-r1.ebuild,v 1.8 2007/07/11 02:54:47 leio Exp $

inherit 

DESCRIPTION="A script (and some initrd utils) for using a smartcard with cryptsetup-LUKS"

HOMEPAGE="https://systemausfall.org/mail-archive/?0::240"

SRC_URI="${PN}.tar.gz"

KEYWORDS="~x86"

LICENSE="LGPL-2.1"

SLOT="0"

IUSE=""

RESTRICT="fetch"

RDEPEND="sys-apps/initramfs-tools

   dev-libs/opensc"

DEPEND="${RDEPEND}"

pkg_nofetch() {

   einfo "Please go to $HOMEPAGE and download the cryptsetup-opensc.tar.gz"

   einfo "package manually. You may have to rename it, as it is served by a script."

}

S=$WORKDIR

src_unpack() {

   unpack "${A}"

}

src_install() {

   cd ${S}

   for item in *; do

      cp -a ${item} ${D}/

   done

   chmod +x ${D}/lib/cryptsetup/scripts/decrypt_opensc \

      ${D}/etc/initramfs-tools/hooks/cryptopensc \

      ${D}/etc/initramfs-tools/scripts/local-top/cryptopensc \

      ${D}/etc/initramfs-tools/scripts/local-bottom/cryptopensc

}

pkg_postinst() {

   einfo "If you wish to use this in a genkernel-made initrd, you will"

   einfo "need to modify /usr/share/genkernel/generic/initrd.scripts."

   einfo "Specifically, you will need to modify the openLUKS function"

   einfo "so that it uses the decrypt_opensc script. The actual change"

   einfo "that you need to make is to replace the line that reads"

   einfo '"cryptsetup luksOpen ${LUKS_DEVICE} ${LUKS_NAME}" with the lines'

   einfo '"/lib/cryptsetup/scripts/decrypt_opensc /boot/YOUR_ENCRYPTED_KEY >/tmp/decrypted_LUKS_key"'

   einfo '"cryptsetup luksOpen ${LUKS_DEVICE} ${LUKS_NAME} --key-file /tmp/decrypted_LUKS_key"'

   einfo 'You will need to run "DESTDIR=/ /etc/initramfs-tools/hooks/cryptopensc"'

   einfo "in order to copy the neccessary executables and libraries"

   einfo "to locations that will be included in the initrd"

   einfo "It is also recommended that you visit ${HOMEPAGE}"

   einfo "for instructions on how to generate (and set up) an encrypted key"

   einfo "for use with this package. This is EXPERIMENTAL, use the"

   einfo "--kernname=smartcard option for genkernel, or otherwise preserve"

   einfo "your previous initrd. Also back up the initrd.scripts file"

   einfo "and keep a bootloader entry pointing to your old initrd"

   einfo "until you have verified that this actually works."

}

```

----------

## 0annygma0

I know, this is realy old topic, but I found them, searching for some answers about similar problem.

My opinion is, that idea to have encryptyng key on smart card is bad idea. Evan, in case of your success, only thing what you will get will be painfully (realy painfuly) slow decrypting mechanism. It is becouse of basic idea of smart card. It will newer get key nobody, it means, that every single operation (signing, encrytping, decrypting, ...) is compute by chip on card. In case of signing its not problem, it takes miliseconds, becouse its compute with one relative short number (hash/checksum of your file/mail/...), but in case of hundreds mega HDD, not even in case of teras. 

But, Im still searching for running configuration with key stored on hdd and protected/encrypt by key on smartcard.

any success i will poste here or in to the new thread on this site

----------

## Roman_Gruber

guys usually use SD-Cards, USB-sticks for that purpose these days.

carry around key + boot.

 *Quote:*   

> but in case of hundreds mega HDD, not even in case of teras. 

 

I think you miss the conecpts of luks.

you just open once the "container" with one of eight possible passwords. Where that password is stored is just not that important. It can be typed in a shell, can be taken from a file or other means. When the container is opened, it's opened.  the encryption layer is temporarily removed and not visible to the user / application anymore. It's just a mount point thats it

----------

## Hu

 *0annygma0 wrote:*   

> I know, this is realy old topic, but I found them, searching for some answers about similar problem.

 You have given us your opinion on why this is a bad idea, but you did not identify any particular problem with which you require assistance.  What do you need us to investigate?

----------

