pup_save encryption --UPDATED again for 2.11

[kirk]

Here's a modified initrd.gz and a script (Encrypt-pupsave) to create a new encrypted pup_save.

The Encrypt-pupsave script will use some X windows to ask you where you want to put your new encrypted pup_save file (best to put it on the same partition) and how big to make it. Then It will prompt you for a password and ask you if you want to copy the files from the current pup_save file. The new file will be named "pup_save_crypt.3fs", unless a file by that name all ready exsists, then it's named the same thing with a number after it.


The initrd.gz has the following modifications:

Added cryptoloop.ko (5KB)
Added aes.ko (22KB)
Replaced the busybox losetup with a staticly compiled version (edit: now it's 29KB)

Added these lines to init:
[quote]
########## crypto added lines 251-260 ######
CRYPT=$( echo $PUPSAVE | grep crypt )
if [ "$CRYPT" != "" ] ; then
CRYPTO="-e aes"
insmod /lib/modules/${KERNVER}/aes.ko
insmod /lib/modules/${KERNVER}/cryptoloop.ko
else
CRYPTO=""
fi
##############################################

######## add crypto lines 575-592, 598 #######
if [ "$CRYPTO" != "" ] ; then
echo -e "\\033[1;31m" >/dev/console
echo "Loading encrypted pup_save_crypt" >/dev/console
echo "" >/dev/console
while true; do
echo "Password: " >/dev/console
losetup $CRYPTO /dev/loop1 $SMNTPT$SAVEFILE
mount -t ext3 -o noatime,rw /dev/loop1 $EFSMNT
if [ "$?" = "0" ] ; then
break
else
losetup -d /dev/loop1
echo "Can't mount file, Try password again." >/dev/console
fi
done
else
#########################
losetup /dev/loop1 $SMNTPT$SAVEFILE
echo -n "Mounting ${SAVEFILE} on ${EFSMNT}..." >/dev/console
FILEFS="ext3"
[ ! "`echo -n "$SAVEFILE" | grep "2fs"`" = "" ] && FILEFS="ext2"
mount -t $FILEFS -o noatime,rw /dev/loop1 $EFSMNT;check_status $?
fi # This line added for crypto

The init script will now check to see if the pup_save file has "crypt" as part of it's name, if it does then you'll be prompted for a password.

To use this you'll have to replace your current initrd.gz and use the script to make a new pup_save file.


I've test it with a frugal install, haven't tried remastering a CD yet. Don't know much about multi-session, probably won't work for that.

[kirk]

This works with the live CD too. I replaced the init.gz with the new one and burned a new CD.

Everything should work the same if you use this init.gz. You'll only see a difference if the pup-save file you choose to use has "crypt" in the name.

[kirk]

Recompiled losetup (2.12r) static with dietlibc, now it's 29KB instead of 407KB!!!

If you want to remaster a CD:

1) Copy all the files from your 2.10 CD to a folder.

2) Replace the initrd.gz with the one posted here.

3) Open a terminal window and type:
mkisofs -o /root/puppy.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /tmp/iso
Where /tmp/iso is the folder you copied the files to and /root/puppy.iso is the new iso file that will made.

4) Burn your new iso.


This change will allow you to have multiple encrypted pup_save files or a mix of encrytped pup_save files and regular pup_save files. If you don't have a pup_save file with crypt in the name you won't see any difference at all.

[debernardis]

This is very interesting and I want definitely to test it.

Shouldn't it be associated to some kind of utility to blank the swap file? Otherwise pieces of your files would be still unsecured. Or better avoid swapfiles at all?

EDIT: it seems to work OK with a cd puppy - no multisession - and pup_save on an hd partition.

[kirk]

Shouldn't it be associated to some kind of utility to blank the swap file?

Yes, and it should have instructions for making a stylish tin hat!

Just kidding, there have been some posts on the forum from people wanting to have multiple secure pup_save files, so that when their kids use the computer they can't mess up their stuff and if lost their personal info would be safe.

This will do that and provide data security should your computer (laptop) fall in to malicious hands. The odds of your data getting into hands of someone who has the knowledge / time / motivation to get some data off your swap file and for that data to be of any use, seems quite remote.

Thanks for testing it out.

Updated the Encrypt-pupsave script so that it pops up a window to tell you its done.

[debernardis]

I see your point but since your script promises to give a nice level of security to the owner's files, why not to raise such level avoiding that random chunck of those files might be left readable to anybody?

So if you want to get rid of this flaw, go get the utility 'shred' from another distro. On my kubuntu I found it in /usr/bin and it is likely to be there also in other distros. Copy that on /usr/local/bin in your puppy, control its permissions (must be executable) and you're done.

Now when have edited your sensible files having a swap partition on and you prefer to wipe all traces of your work from it, do as follows:
1) go to MUT, find your swap partition and click on swap off.
2) open a terminal and do:

Code: Select all

 shred -v  /dev/WHATEVER 

- of course 'whatever' is the name of your swap partition, i.e. /dev/hda7. Get the name/number from MUT. Beware, shred sill destroy your data if you make a mistake with its syntax, so triple check before you press ENTER, and don't do it when you're tired!
3) Wait. Wait. Wait. You asked shred to be verbose so you can follow the progression of its work in the console window Shred will overwrite with nonsignificant data your swap partition for 25 times (this can be changed). If you would stop it with ctrl-c, say at the 12nd pass, well... might be that your data are shredded enough and you have saved half the time.
4) Now your swap partition isn't a swap partition any more. It's a raw desert of unsignificant octets. Since you most likely wish to restore it as a swap space, go fire Gparted (should be on your Control Panel menu on JWM), select your now unformatted partition, then by the menus Partition-Format to-Linux Swap, then apply, then you're done.
5) Back to MUT, you can now click on 'Use Swap' and your computer will be in the same state as before you started.

Shred is also good for wiping single files, other than partitions. Here's its help:

sh-3.00# shred --help
Usage: shred [OPTIONS] FILE [...]
Overwrite the specified FILE(s) repeatedly, in order to make it harder
for even very expensive hardware probing to recover the data.

Mandatory arguments to long options are mandatory for short options too.
-f, --force change permissions to allow writing if necessary
-n, --iterations=N Overwrite N times instead of the default (25)
-s, --size=N shred this many bytes (suffixes like K, M, G accepted)
-u, --remove truncate and remove file after overwriting
-v, --verbose show progress
-x, --exact do not round file sizes up to the next full block;
this is the default for non-regular files
-z, --zero add a final overwrite with zeros to hide shredding
--help display this help and exit
--version output version information and exit

If FILE is -, shred standard output.

Delete FILE(s) if --remove (-u) is specified. The default is not to remove
the files because it is common to operate on device files like /dev/hda,
and those files usually should not be removed. When operating on regular
files, most people use the --remove option.
CAUTION: Note that shred relies on a very important assumption:
that the file system overwrites data in place. This is the traditional
way to do things, but many modern file system designs do not satisfy this
assumption. The following are examples of file systems on which shred is
not effective, or is not guaranteed to be effective in all file system modes:

* log-structured or journaled file systems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

* file systems that write redundant data and carry on even if some writes
fail, such as RAID-based file systems

* file systems that make snapshots, such as Network Appliance's NFS server

* file systems that cache in temporary locations, such as NFS
version 3 clients

* compressed file systems

In the case of ext3 file systems, the above disclaimer applies
(and shred is thus of limited effectiveness) only in data=journal mode,
which journals file data in addition to just metadata. In both the
data=ordered (default) and data=writeback modes, shred works as usual.
Ext3 journaling modes can be changed by adding the data=something option
to the mount options for a particular file system in the /etc/fstab file,
as documented in the mount man page (man mount).

In addition, file system backups and remote mirrors may contain copies
of the file that cannot be removed, and that will allow a shredded file
to be recovered later.

Report bugs to <bug-coreutils@gnu.org>

[jam]

This should also work if you want to scramble/zero out data on swap partition:

Code: Select all

swapoff <swap-device>

Randomize:  dd if=/dev/urandom of=<swap-device>

                      OR 

Zero Out:   dd if=/dev/zero of=<swap-device>

[kirk]

Security systems are inherently flawed. If the owner of the system can get in, then somebody else can too. So the goal is to make it difficult or improbable for that somebody else to do so. But, you don't want to make it difficult or improbable for your self. So you should consider the risks and rewards of your system. I could add an extra lock to the front door of my house. This would make it more difficult for someone to break in. But, it would also make it more difficult for me to get in every time I come home. If I lived in a high crime area perhaps I'd consider the second lock. To me the risks of somebody actually getting something off my swap partition and for that data to be of any use is very very low. And the cost (time / space) seems high. But others my face a different circumstance.

If you want to wipe your swap partition you could also do this:

1) If you don't remember which partition your swap is on:
# probepart

2) Turn off swap
# swapoff /dev/hda5 (if your swap is on hda5!)

3) Fill the swap with sudo-random numbers. BE VERY CAREFUL TO USE THE CORRECT PARTITION.
# dd if=/dev/urandom of=/dev/hda5 (if your swap is on hda5!)

4) Re-setup swap.
# mkswap /dev/hda5

5) Turn swap back on.
# swapon /dev/hda5

And for the tin hat crowd you could repeat step 3 as many times as you like.

[marksouth2000]

4) Now your swap partition isn't a swap partition any more. It's a raw desert of unsignificant octets. Since you most likely wish to restore it as a swap space, go fire Gparted (should be on your Control Panel menu on JWM), select your now unformatted partition, then by the menus Partition-Format to-Linux Swap, then apply, then you're done.

As long as it still is listed as swap in the partition table (hopefully you didn't nuke that!) then you only need to use "mkswap -v1" on it and then do "swapon -a". No need for a partition editor.

Now, while it's interesting watching people discover things in discussion, all this data security stuff is already well worked out and already available on the net. Searching for "Darik's Boot and Nuke" will turn up all the relevant links to DBAN and related tools for wiping information properly.

[debernardis]

Thanks jam, kirk, mark, I have learned something.

Would you please have a look at the attached script which, in my intentions, should automate swapfile wiping? I am quite a noob at that and don't want to ruin my or other people's machine

I think the script is bound to fail if there are more then one swapfile... but indeed there are enough warnings to stop it if something seems unusual.

Thanks...

[gliezl]

3) Open a terminal window and type:
mkisofs -o /root/puppy.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /tmp/iso

where will I get a new isolinux.bin? In the case of Slax remastering, it copies a new isolinux.bin to the CD root. Will it not affect Puppy remastering? I just want to make sure...

Thanks

[jam]

debernardis,

Once I remaster my current Puppy config I have a test machine I can afford to "trash" , so I can test your script without any serious consequences.

[kirk]

Gliezl,

Just copy everything from the original Puppy 2.10 CD to /tmp/iso (or where ever you have space) except initrd.gz. Use the one posted here.

[kirk]

debernardis,

Tried your script. The one pass works, but the shred option doesn't because I don't have a shred command.

[debernardis]

Tried your script. The one pass works, but the shred option doesn't because I don't have a shred command.

Here's shred (taken from kubuntu 6.06)

[PaulBx1]

Ah, the software-oriented mind at work.

Of course us hardware types just buy more memory and don't use swap at all. Problem solved (except maybe if I'm trying to recompile the linux kernel or something - but then I'd just do that on an unencrypted machine...)

I am very interested in trying this new initrd, and I'm glad it works with unencrypted pup_saves too (so maybe someday it will work its way into standard Puppy linux). Now that I've got a decent internet connection, I will give it a try. Thanks, kirk, and the rest of you...

Oh, by the way, could you tell me if the initrd you applied this change to is the 2.10r1 version? From the timing, I am guessing it is not...

[kirk]

It's for 2.10. If you try it let me know what you think.

Thanks,
kirk

[John Doe]

Great job getting this into a working system.

I'll poke around a bit more at designing a shutdown for integration into puppy.

Maybe when Barry gets back we can get this together with him for integration (if he's interested) into the main puppy branch.

I've been fighting some hardware problems on my end and have been pretty absent online lately.

[PaulBx1]

kirk, looks like it works great, although I haven't poked around in the encrypted pup_save to see if it actually is encrypted, heh, and I haven't done any performance testing either. But the initial impression is that it works (tested in a "frugal install").

A couple of suggestions with the script:

1) do the insmods inside the test for encryption; no need to load these modules if there is no encrypted pup_save.

2) In the dialog that asks for a password, I started typing the password before bringing up the xterm. The dialog should indicate that by pushing the (OKAY?) button you will be bringing up the xterm in which the password will be entered.

3) Then, when entering the password (call it "passphrase" everywhere, if it isn't already), you should ask for it twice and then compare, as normal new-password dialogs go.

4) Finally, I hope you make these and any other changes on the 210r1 initrd, which will simplify life considerably. I'm also trying to get my stuff going on a flash drive - flash drives and encrypted Puppy go together well...

Great work, kirk! BTW, can you give us the big picture - is this aes256 encryption pretty strong? How does it compare with what Truecrypt offers?

[jam]

PaulBx1,

To respond to your question concerning the strength of AES-256 Bit encryption:

AES stands for Advanced Encryption Standard. AES is a symmetric key encryption technique which will replace the commonly used Data Encryption Standard (DES).

It was the result of a worldwide call for submissions of encryption algorithms issued by the US Government's National Institute of Standards and Technology (NIST) in 1997 and completed in 2000.

The winning algorithm, Rijndael, was developed by two Belgian cryptologists, Vincent Rijmen and Joan Daemen.

AES provides strong encryption and has been selected by NIST as a Federal Information Processing Standard in November 2001 (FIPS-197), and in June 2003 the U.S. Government (NSA) announced that AES is secure enough to protect classified information up to the TOP SECRET level, which is the highest security level and defined as information which would cause "exceptionally grave damage" to national security if disclosed to the public.

Cheers!