Tue 07 of Sep, 2010 [00:19 UTC]

cdrom

coach outlet

English

cdrecord

Maximilian has created a patch for cdrecord that will encrypt the data being burned on-the-fly, get the patch here.

Burning the cd

After patching cdrecord:
Create encrypted cdrom from standard iso image for use with dm-crypt:
# cdrecord -dev=0,0,0 -encrypt -encpass=mypassword image.iso
Or alternately, if you would like to put the password in a file:
# cdrecord -dev=0,0,0 -encrypt -encpassfile=path/to/passfile image.iso

Note:
cdrecord may not like trailing linefeeds, newlines, etc., at the end of the file. Even though hashalot's sha256 returns the same hash on a file that varies only be the ending type (newline, linefeed, or nothing), I suspect that cdrecord may hash each of these variants differently. Until someone can test this, I reccommend using NO end-of-file or end-of-line characters. Use "echo -n foo > testpass", "dd if=/dev/urandom of=testpass bs=1 count=32" or similar, but not a text editor.

Mounting the cd using cryptsetup version 0.1

# losetup /dev/loop0 /dev/cdrom
# cryptsetup -c aes -s 256 -h sha256 create cdrom /dev/loop0
Password:
# mount /dev/mapper/cdrom /mnt/cdrom

Note:
cryptsetup-0.1 has a bug that prevents setting up encrypted mappers for read-only devices.
You will have to workaround with" losetup /dev/loop0 /dev/cdrom" and use /dev/loop0 for cryptsetup.
Current versions (in CVS) already fixed this issue, and encrypted cdroms should work fine with the next cryptsetup (not released yet ...).

Mounting the cd without interactian using cryptsetup version 0.1

If you want to mount the CD without user interaction (that is to say, no "Password" prompt), you will need to do the following:
1. Get the HASH of your password.
# cat path/to/passfile | sha256 > passhash
2. Set up the loopback as before
# losetup /dev/loop0 /dev/cdrom
3. Run cryptsetup with the "-d" option, with a path to the file holding the HASH of your password.
# cryptsetup -c aes -s 256 -h sha256 -d path/to/passhash create cdrom /dev/loop0
4. Mount the decrypted CD as before
# mount /dev/mapper/cdrom /mnt/cdrom

Note that the above is useful in instances where you have a physical "token" in stead of or in conjunction with a password.

Mounting the cd using cryptsetup version 0.2 and above (not released yet)

# cryptsetup -r -c aes -s 256 -h sha256 create cdrom /dev/mapper/cdrom
Password:
# mount /dev/mapper/cdrom /mnt/cdrom

Note the added -r to cryptsetup (read-only), added in v0.2

Other info (old)

create:

mkisofs -J -R . | aespipe -H sha256 -e aes256 > image.iso
growisofs -Z /dev/dvd=image.iso (cdrecord image.iso)
mount:

losetup /dev/loop0 /dev/dvd
cryptsetup  -c aes -s 256 -h sha256 create crypt1 /dev/loop0
mount /dev/mapper/crypt1 /mnt/ccdrom/

(there is a bug in cryptsetup-0.1 that prevents mounting readonly media directly, you have to use losetup workaround for now)

you can also use the executable-map -feature of an automounter to automatically determine if the CD/DVD is encrypted and set things up.
The format is as follows:

/etc/auto.master contains a line

/mnt/auto       /etc/automount.sh       --timeout=2

and /etc/automount.sh is a script that gets the mountpoint as ${1] (for example $1=cdrom for accesses to /mnt/auto/cdrom)
and returns a mountline line "-fstype=$fs,users,exec,$options :$device" but can do anything in between.
It can determine if there is an unencrypted iso9660 and if not do losetup and cryptsetup and return a mount-line for the loopback-device.

a possible script looks as follows:

if [ "$1" = "cdrom" ] ; then

 ############################
 # break down the cryptoloop
 #
 cryptsetup remove crypt1
 losetup -d /dev/loop0
echo 1
 ############################
 # do this and exit if the disc is not encrypted at all
 #
  isoinfo -i /dev/hdc && echo "-fstype=iso9660,users,exec,ro        :/dev/hdc" && exit

echo 2
 ############################
 # ask the user for the passphrase and set up the loopback-encryption
 # TODO: user is hard-coded here because root as no access to a users X11-display
 # [[http://www.college-paper.org/custom-essay.html|college essay]]
 losetup /dev/loop0 /dev/hdc
 su fox -c "export DISPLAY=:0.0 && ssh-askpass" | cryptsetup -c aes -s 256 -h sha256 create crypt1 /dev/loop0
 echo "-fstype=iso9660,users,exec,ro        :/dev/mapper/crypt1";

 exit
fi

One problem is still unmounting an encrypted cdrom this way as only the loop is unmounted by the automounter
but to eject the cd the loop must be removed manually or via a shell-script like "crypteject".
Please tell me Marcus@Wolschon.biz if you find any good improvements to this method! :)

A replacement-script for cdrecord might look like:

#!/bin/bash
# this script is called instead of cdrecord and calles cdrecord internally but encryptes the iso on the fly
# ssh-askpass is used to ask for the passwort (ONLY ONCE!!)
su fox -c "export DISPLAY=:0.0 && ssh-askpass" 4>&1- ||  cat  | aespipe -H sha256 -e aes256  -p 4 | cdrecord $*

Created by: a1bert last modification: Thursday 05 of August, 2010 [12:38:09 UTC] by Anonymous

edit

4 comments

Posted messages

Messages

Style

Sort

Threshold

Find

Top

Hide all

author

message

chrism

burning non-iso images to a CD

on: Sat 12 of Mar, 2005 [22:02 UTC]

score: 0.00

By encrypting an ISO and burning that to a CD, you are in effect burning an arbitrary image to the CD. I suspect that will cause problems, even though you are supposed to be able to burn arbitrary filesystems or images to a CD. I did some experiments using losetup, dmsetup, cdrecord, and using an ext2 filesystem and couldn't get it to work. That is, I couldn't mount the CD after burning it.

Inelegant as it may seem, I am beginning to suspect that the easiest way to get it to work is to burn an ISO containing a single file. That file would be an encrypted ext2 filesystem. So you would mount the CD as an ISOFS, then losetup the file inside it, dmmap the /dev/loop device, then mount the dev/mapper device as an ext2.

I wonder how much of a performance penalty that would be? I always imagined the isofs filesystem as being carefully designed to make the reading process as efficient as possible for CD media, so perhaps it would be even faster than burning an encrypted ISOFS directly would be.

author

message

lucho

burn an encrypted dvd with growisofs

on: Sun 29 of May, 2005 [19:21 UTC]

score: 0.00

A bit longer way to do it, but it doesn't require patching or even using cdrecord
# make sure cryptoloop is loaded
modprobe cryptoloop
# create a big random file
dd if=/dev/urandom of=~/.crypto bs=1024k count=4000
# setup the loop device to point there
losetup /dev/loop0 ~/.crypto
# do the encrypted mapping
cryptsetup -c serpent -y -s 256 create cryptodvd /dev/loop0

# create the filesystem and mount it
mke2fs /dev/mapper/cryptodvd
mount /dev/mapper/cryptodvd /mnt/hd/tmp/
# copy stuff into it
cp -R whatever /mnt/hd/tmp
# burn it to the dvd
growisofs -use-the-force-luke=dao -dvd-compat -Z /dev/hdd=~/.crypto -speed=2
# I do this to cleanup. Don't know if it is required
cryptsetup remove cryptodvd
losetup -d /dev/loop0
# now you can use like so:
losetup /dev/loop0 /dev/hdd
cryptsetup -c serpent -s 256 create cryptodvd /dev/loop0
mount -t ext2 /dev/mapper/cryptodvd /mnt/hd/tmp/
# ... you use your files here
cd /mnt/hd/tmp
# done, cleanup
umount /dev/mapper/cryptodvd
cryptsetup remove cryptodvd
losetup -d /dev/loop0

author

message

ai2097

Re: burning non-iso images to a CD

on: Mon 09 of May, 2005 [20:19 UTC]

score: 0.00

Burning the ext2 filesystem image onto a CD likely didn't work because of the difference in block sizes between how the fs was made, and how the CD actually is. IIRC, CDs have some oddball block sizes (roughly over 2k; not a nice, even power of 2). Since filesystems are very sensitive to exactly how big a block is (that's how they address all of the data), when block sizes don't match what the FS is expecting, you're in trouble.

Also note that we aren't truly writing "raw" data to the disk, per se; we're writing data that's completely valid size- and padding-wise according to mkisofs. The only difference is that the data happens to be scrambled razz

author

message

johnny

Space and pktcdvd

on: Fri 02 of Dec, 2005 [08:52 UTC]

score: 0.00

Don't forget to fill the device completely, length is information. If possible, try to ensure that the file system doesn't start at the beginning of the disk (is this possible?). Possibly creative use of dot files can help achieve this if mkisofs doesn't allow arbitrary file placement.

It is also possible to setup encryption on top of the packet writing device (see pktcdvd module). I forget if I used the raw device or a file in a file system.

Page: 1/1
1


Wiki	Blogs
Acticles	Forums
File galleries	Image galleries

Page generated in: 0.14 seconds