Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Sun, 08 Mar 2009
USB flash drives and SD cards are getting so big -- you can really
carry a lot of stuff around on them. Like a backup of your mail
directory, your dot files, your website, stuff you'd really rather
not lose. You can even slip an SD card into your wallet.
But that convenient small size also means it's easy to lose your
USB key, or leave it somewhere. Someone could pick it up and have
access to anything you put there. Wouldn't it be nice to encrypt it?
There are lots of howtos on the net, like
this and
this,
but most of them are out of date and need a bit of fiddling to get
working. So here's one that works on Ubuntu hardy and a 2.6.28 kernel.
I'll assume that the drive is on /dev/sdb.
First, consider making two partitions on the flash drive.
The first partition is a normal unencrypted vfat partition, so you can
use it to transfer files to other machines, even Windows and Mac.
The second partition will be your encrypted file system.
Use fdisk, gparted or your favorite partitioning
tool to make the partitions, then create a filesystem on the first:
mkfs.vfat /dev/sdb1
Update:
On many distros you'll probably need to load the "cryptoloop" module
before proceeding with the following steps. Mount it like this (as root):
modprobe cyptoloop
Easy, moderate security version
Now create the encrypted partition (you'll need to be root).
I'll start with a relatively low security version -- good enough to
keep out most casual snoops who happen to pick up your flash drive.
losetup -e aes /dev/loop0 /dev/sdb2
[type a password or pass phrase]
mkfs.ext2 /dev/loop0
losetup -d /dev/loop0
I used ext2 as the filesystem type. I want a Linux filesystem, not a
Windows one, so I can store dot-filenames like .gnupg/ and so I can
make symbolic links. I chose ext2 rather
than a journalled filesystem like ext3 because of kernel configuration
warnings: to get encrypted mounts working I had to enable
loopback and cryptoloop support under drivers/block
devices, and the cryptoloop help says:
WARNING: This device is not safe for journaled file systems like
ext3 or Reiserfs. Please use the Device Mapper crypto module
instead, which can be configured to be on-disk compatible with the
cryptoloop device.
I hunted around a bit for this "device mapper crypto module" and
couldn't figure out where or what it was (I wish kernel help files
would give either the path to the option, or the CONFIG_ name in
.config!) so I decided I'd better stick with non-journalled
filesystems for the time being.
Now the filesystem is ready to use. Mount it with:
mount -o loop,encryption=aes /dev/sdb2 /mnt
[type your password/phrase]
Higher security version
There are several ways you can increase security. Of course, you can
choose other encryption algorithms than aes -- that choice is up to you.
You can also use a random key, rather than a password you type in.
Save the random key to a file on your system (obviously, you'll want
to back that up somewhere else). This has both advantages and
disadvantages: anyone who has access to your computer has the key
and can read your encrypted disk, but on the other hand, someone who
finds your flash drive somewhere will be very, very unlikely to be
able to use it. Set up a random key like this:
dd if=/dev/random > /etc/loop.key bs=1 count=60
mkfs.ext2 /dev/loop0
losetup -e aes -p 0 /dev/loop0 /dev/sdb2 < /etc/loop.key
(of course, you can make it quite a bit longer than 60 bytes).
(Update: skipped mkfs.ext2 step originally.)
Then mount it with:
cat /etc/loop.key | mount -p0 -o loop,encryption=aes /dev/sdb2 /crypt
Finally, most file systems write predictable data, like superblock
backups, at predictable places. This can make it easier for someone to
break your encryption. In theory, you can foil this by specifying
an offset so those locations are no longer so predictable.
Add -o 123456 (of course, use your own offset, not that
one) to the losetup line, and ,offset=123456
in the options of the mount command.
In practice, though, offset doesn't work for me: I get
ioctl: LOOP_SET_STATUS: Invalid argument
whenever I try to specify an offset. I haven't pursued it;
I'm not trying to hide state secrets, so
I'm more worried about putting off casual snoops and data thieves.
Tags: linux, security, filesystems, backups
[
14:10 Mar 08, 2009
More tech/security |
permalink to this entry
]
Thu, 21 Aug 2008
Chase sent us replacement MasterCards out of the blue. They came with
a brochure touting their wonderful new
Chase's
"Blink"
feature. So convenient! You just hold the card near a reader
and it charges your account, no need for any of that pesky swiping
of cards or signing of forms!
Yes, it's RFID (Radio Frequency ID tags), the small low-power radio
transmitters also used by Walmart and various other retailers,
and in other applications such as company security badges/access cards
(and, unfortunately, new passports in quite a few countries).
It seems a little odd to me that Chase's marketing implies that most
people would think it's a good thing to have a credit card that
can be charged easily without even taking it out of your wallet ...
to have a card that can be charged from some distance away without
your even knowing about it.
It's apparently easy and cheap to build an RFID credit card skimmer:
Bruce Schneier has
collected
several articles about it, and in a later article he
offers several links to articles on how to
build
your own RFID skimmer.
We called Chase right away and told them we didn't want the "Blink"
cards. They said we could keep our old, non-RFID cards and continue
to use them, and destroy the new ones. Whew!
Googling for links for this article, I found that we're not
the only Chase customers to want to decline Blink.
For anyone wondering how secure this technology is, the recent
debacle of the cracked Dutch RFID subway cards gives you an idea
(Bruce
Schneier, "Dutch RFID Transit Card Hacked";
The
Register, "Dutch transit card crippled by multihacks",
and a followup where the MBTA, Boston's transit agency,
used
the courts to muzzle three MIT students who were trying to present
a paper at Defcon on the security holes in the MBTA's RFID-based pay system.
For anyone who gets stuck with an RFID credit card, here's how to make an
RFID-blocking
wallet, and how to make an
RFID
zapper.
Tags: RFID, security, finance
[
10:26 Aug 21, 2008
More tech/security |
permalink to this entry
]
Tue, 24 Oct 2006
I get tons of phishing scam emails spoofing Amazon. You know, the
ones that say "Your Amazon account may have been compromised: please
click here to log in and verify your identity", and if you look at the
link, it goes to
http://123.45.67.8/morestuff instead of
http://www.amazon.com/morestuff. I get lots of similar phishing
emails spoofing ebay and various banks.
But yesterday's was different. The URL was this:
http://www.amazon.com/gp/amabot/?pf_rd_url=http://211.75.237.149/%20%20/amazon/xec.php?cmd=sign-in
Check it out: they're actually using amazon.com, and Amazon has a 'bot
called amabot that redirects you to somewhere else. Try this, for
example:
http://www.amazon.com/gp/amabot/?pf_rd_url=http://bn.com
-- you start on Amazon's site and end up at Barnes & Noble.
When a family member got tricked by a phish email a few months ago
(fortunately she became suspicious and stopped before revealing
anything important)
I gave her a quick lesson in how URLs work and how to recognize the
host part. "If the host part isn't what you think it should be,
it's probably a scam," I told her. That's pretty much the same as what
Amazon says (#6 on their "Identifying Phishing or Spoofed E-mails"
page). I guess now I need to teach her how to notice
that there's another URL embedded in the original one, even when the
original one goes to the right place. That's a bit more advanced.
I suspect a lot of anti-phishing software uses the same technique and
wouldn't have flagged this URL.
I reported the phish to Amazon (so far, just an automated reply, but
it hasn't been very long). I hope they look into this use of their
amabot and consider whether such a major phishing target really needs
a 'bot that can redirect anywhere on the net.
Tags: tech, web, security
[
10:34 Oct 24, 2006
More tech/web |
permalink to this entry
]
Sun, 14 Aug 2005
I bet I'm not the only one who uses Ubuntu (Hoary Hedgehog) and didn't
realize that it doesn't automatically put the security sources in
/etc/apt/sources.list, so apt-get and aptitude don't pick up
any of the security updates without extra help.
After about a month with no security updates on any ubuntu machines
(during which time I know there were security alerts in Debian for
packages I use), I finally tracked down the answer.
It turns out that if you use synaptic, click on "Mark All Upgrades",
then click on Apply, synaptic will pull in security updates.
However, if you use the "Ubuntu Upgrade Manager" in the
System->Administration menu, or if you use commands
like apt-get -f dist-upgrade or aptitude -f dist-upgrade,
then the sources which synaptic wrote into sources.list are not
sufficient to get the security updates.
(Where synaptic keeps its extra sources, I still don't know.)
When I asked about this on #ubuntu, I was pointed to a page on
the Ubuntu wiki which walks you through selecting sources in synaptic.
Unfortunately, the screenshots on the wiki show lots of sources that
none of my Ubuntu machines show, and the wiki doesn't give you the
sources.list lines or tell you what to do if synaptic doesn't
automagically show the security sources.
The solution: to edit /etc/apt/sources.list and make sure the
following lines are there (which some of the people on the IRC channel
were kind enough to paste for me):
## All officially supported packages, including security- and other updates
deb http://archive.ubuntu.com/ubuntu hoary main restricted
deb http://security.ubuntu.com/ubuntu hoary-security main restricted
deb http://archive.ubuntu.com/ubuntu hoary-updates main restricted
In addition, if you use "universe" and "multiverse", you probably also
want these lines:
deb http://archive.ubuntu.com/ubuntu hoary universe multiverse
deb http://security.ubuntu.com/ubuntu hoary-security universe multiverse
deb http://archive.ubuntu.com/ubuntu hoary-updates universe multiverse
Tags: linux, ubuntu, security
[
21:49 Aug 14, 2005
More linux |
permalink to this entry
]
Sat, 24 Jul 2004
We had dinner with Tim and Pam last night (visiting for AstroCon)
at "Skates on the Bay" in Berkeley -- excellent food.
so I told Tim about the virus attack on
Shallow-Sky
a few days ago, perpetrated in his name.
Messages were sent to the list, ostensibly from his address,
containing various attachments which were obviously Windows viruses.
Unfortunately, I was out on a hike when the attack happened, so five
of them slipped through before I found out about it and blocked
his address in order to investigate further.
The virus turned out to be
W32.Beagle.AG@mm
(W32 is obvious, and f3ew tells me that "mm" stands for "mass
mailing").
Pasc gave me a procmail rule to block this virus, to put in
smartlist's rc.submit. It should have worked, but it didn't,
so I ended up using a more general rule to block all base64 encoded
attachments (that'll probably piss off some people who like to send
images to one of our other lists, but Dave says he's asked them not
to do that anyway and doesn't mind having the rule there).
Of course, the messages weren't really coming from Tim: he doesn't
even use Windows (Mac and Sun, usually). It turns out they're
coming from a Comcast address, which doesn't narrow things down
much. There are nine @comcast.net addresses on the list, so I
notified them privately, but it could easily be someone else or
even someone off the list (though I suspect it's a list member,
since it's someone who has Shallow in their addressbook).
I suppose I'll probably never know who it was. The "Tim" attacks
have stopped (so I don't even know for sure that my filter works,
though it worked for a test message I sent) but I've gotten two
attempts spoofing Peter J (who is not currently on the list, so
they bounced with "Not on accept list" before they could test the
filter).
Grumble grumble Windows security grumble ...
Tags: linux, security
[
14:13 Jul 24, 2004
More linux |
permalink to this entry
]
![[feed]](http://shallowsky.com/images/logos/feed-icon-14x14.png){kind=icon}