Now is probably a good time to mention that I have a paper shredder. When I was shopping for a shredder, the basic requirement is that it must be relatively “secure”. Straight cut shredders (that produce long straight strips) are definitely not secure.
Ultimately I settled on the CARL DS-3000 personal paper shredder. The DS-3000 is a cross-cut shredder which produces “particles” no larger than 2mm x 4.5mm and this meets DIN security level 4. These days, the NSA mandates 1mm x 5mm “particles” for classified documents.
At this point, it’s probably helpful to show you what my shredder bin looks like:
From the particles, you can make out various truncated words such as “A/C”, “exp” and the number “5”, but it’s almost impossible to reconstruct any bank balances or personal information from it.
This particular model was the right balance between my budget and the level of security. Plus, the shredder is compact enough to sit on your desk. I bought it in 2009 and I use it every couple of months when I have accumulated enough material that needs to be destroyed.
I was in the middle of shredding papers when it suddenly stopped working. Now the shredder does not respond when I stick paper into its slot. The LED indicator looks dimmer than usual when it is turned on.
But I’m not ready to give up on it just yet…
The 31st Chaos Communication Congress (31C3) ended just 3 days ago, and there were several interesting talks.
They have got live streaming of the event over the web, as well as encourage you to use an external player with RTMP or HLS support. The video streams were very reliable and best of all, it’s available in HD. In comparison, I tried the Apple live event once and it was really crappy. For one, the HLS1 URL is not publicly available , so someone had to dig that out and post it. Even after that, the audio stream was (I believe, unintentionally) a mix of both English and Chinese simultaneously.
The 31C3 video recordings were also uploaded very quickly after the event. This is much quicker than other events such as Black Hat (although as an attendee, you do get a copy of the stuff on a DVD). A really big kudos to the organizers and the video production team!
If you don’t have time to listen to each and every talk, here are a few selected talks that were interesting to me, as well as a short summary to see if it’s worth 30 or 60 minutes of your time.
A full list of talks can be found here: http://media.ccc.de/browse/congress/2014/index.html
Inspired by Nikolay Elenkov’s detailed technical posts on Android Explorations, I decided to dig into the Android source code myself and document the package verification mechanism in Android.
Package verification was introduced in Android 4.2 to allow for apps to be verified or checked before they are installed. If you have tried to install a malicious app on a production Android device, you might have seen the following screen, displayed by the verifier:
Android was built in such a way that it tries to be generic for third-parties to implement stuff. Package verification is a feature that is currently only used and implemented by Google, but it is abstracted in such a way that any manufacturer can implement their own. Documentation and examples on how to do this is almost non-existent, although anyone determined enough can read the Android source code and figure it out for themselves.
Some weeks back, we were forced to reboot one of our server machines because it stopped responding. When the machine came back up, we were greeted with a password prompt to decrypt the partition. No problem, since we always used a password combination (ok, permutation) that consisted of a few words, something along the lines of “john”, “doe”, “1954”, and the server’s serial number. Except that it didn’t work, and we forgot the permutation rules AND whether we used “john” “doe” or “jack” “daniels”.
All the search results for bruteforcing LUKS are largely the same — “use
cryptsetup luksOpen --test-passphrase“. In my case, the physical server is in the server room, and I don’t want to stand in front of the rack trying to figure all this out. My question is, can I do this offline on another machine? None of those blog entries were helpful in this regard.
The LUKS Header
To answer this question, I took a look at the LUKS header. This header is what provides multiple “key slots”, allowing you to specify up to 8 passwords or key files that can decrypt the volume. cryptsetup is the standard userspace tool (and library) to manipulate and mount LUKS volumes. Since LUKS was designed based on TKS1, the TKS1 document referenced by the cryptsetup project was very helpful. After consulting the documentation & code, I came up with the following diagram that describes the LUKS key verification process:
I have always been an advocate on storage security (all types of security, actually). I like how iOS devices keep all files encrypted, even if you do not set a passcode on the device. They do this to facilitate quick erasure of files on the device — to erase all the data, they simply wipe the master key.
Erasing magnetic storage media isn’t difficult, but it is time-consuming. For solid state media such as SSDs and flash drives, the wear-leveling makes it difficult to ensure that all flash blocks have been securely overwritten. The answer to this is to encrypt everything.
Recently I have been busy building a Linux-based NAS and I decided to put this to practice.