Anyways, the offer boasted…

• A HASP HL “Time” dongle with built-in AES, host-accessible 4kB EEPROM, and “tamperproof” real-time clock (RTC).
• A cross-platform SDK with libraries and example code in C and a handful of other languages.
• Printed API documentation.

After pestering them with a few emails over the course of a week, AKS sent me the kit and it arrived just in time to distract me from the first round of exams during my Senior year `X|`

The SDK includes a demo application which can…

• Read/write the token’s EEPROM.
• Ask the token to encrypt/decrypt data with its key.
• Read the RTC.

To prevent its use in a commercial setting, AKS hard-codes the encryption keys on its evaluation kit tokens.

So, I set out to make use of one of the ”un-crippled” features: the on-token EEPROM. Claiming 1,000,000+ read/write cycles, it seems like a nice place to store ”my own” encryption keys or perhaps store two-factor authentication data.

I hacked up the demo application to implement a bare-bones FUSE filesystem – one which provides a single file, `hello`, backed by the token’s EEPROM. I call the result “haspfuse“.

Here are its limitations. See the haspfuse code for details.

• The filesystem only supports a single file. This wouldn’t be too bad if you were to stack a fuse-zip or archivemount-based tarball-backed filesystem on top. Don’t even think about JFFS(2) or ext2 – they each require more than 4kB for a single block.
• The single file has a fixed size of 3584.
• No operation besides: `getattr`, `readdir`, `open`, `read`, `write`, `truncate`, and `chmod` is supported.
• The filesystem probably isn’t “eject-safe”. See FUSE’s `direct_io` for a starting point.

Additionally, a proprietary blob “driver” named `aksusbd` and a static library from the SDK named `libhasp_linux.a` are required. I had trouble with version 3.5.0 so I included v1.8.1 with the haspfuse code.

`aksusbd` is a userspace driver that employs usbfs to interact with the token. Unfortunately, the deprecation of usbfs is apparently now complete with the release of the 2.6.31.20 Ubuntu kernel. This means that the old standby methods for re-enabling it no longer work.

You’ll need to use a custom kernel with usbfs support, or better yet, develop an open source driver for these tokens!

The latter approach would be especially helpful because my friend Bob claims that “`aksusbd` is setuid root and full of vulnerabilities”. But that’s another story…

Be aware that various AKS licenses and draconian US laws may prohibit you from reverse engineering `akusbd`.

• Filesystem design for severely space-constrained storage devices.
• How to build a virtual filesystem using the FUSE C API.
• Methods for rebuilding ELF symbol tables and the idiosyncrasies that result when the binary is dynamically-linked and uses the Native POSIX Thread Library (NTPL).
• The software tools available for USB protocol reversing.
• The myriad sorts of implementation failures that lead to “cracked” hardware tokens.

• etokenonlinux.org – A great resource for using other AKS tokens to do two-factor authentication, one-time password storage, and encrypted partition unlocking The Right Way™. Provided by Cornelius Koelbel.
• Guy-Gregoire Leclercq’s detailed notes on using the eToken 64k with OpenCT/OpenSC on Debian.
• Andy Smith’s rebuilt, OpenSC-enabled, openssh-client and how to store SSH keys on an eToken with it.

1. Well, mortals too squeamish to run Plan 9 as their every-day operating system ;]

“A5/1 [the encryption scheme used in most cellular voice calls] has operated unchanged for the last 21 years but it has now reached its cryptographic end-of-life, engulfed by the march of Moore’s Law. However, the operational end-of-life of A5/1 may still be decades away as there are approximately 2 billion GSM subscribers, commanding about 80% of the global mobile market. This would be a tough product recall indeed. A5/1 is well-positioned to become the NT of the mobile crypto world, and I see the makings of a long tail of GSM vulnerability.” - Dr. Luke O’Connor at NoTricks: Another crack at open Rainbow Tables for A5/1

The ability to intercept and decrypt GSM cell phone conversations is now well within the reach of hobbyists.¹²

My friend Scott and I were discussing this sobering fact one night and we began wondering if any systems exist which provide end-to-end encryption for this insecure link.

Sure, there are plenty of solutions for people with access to cellular dataconnections, but what can voice call participants use to foil eavesdroppers?

We didn’t find any low-cost systems so we decided to create our own. OKCrypto is the Linux-based encrypting software modem that we’ve made. It consists of two components: the modem component and crypto component.

We needed the ability to send data before we could try sending  encrypteddata, so the first step was to design a simple software modem.

Rather than executing the modem code on the cell phones themselves, I decided to host the modem code on a the sender and receiver’s Linux systems. This design provides two benefits:

1. The modem code and crypto code has access to the rich Linux API.
2. Sensitive code and data are isolated from the both the cell phone itself and from the cell infrastructure. We have clean separation between trusted (PC) and untrusted (cell) environments.

Thus, the “real work” in OKCrypto is done on the PC – the cell phones simply allow the PCs to talk to each other. See figure 1 for an overview of the hardware involved in the system.

Conceptually, the modem is similar to the analog Plain Old Telephone Service (POTS) modems from the Bad Old Days before broadband service became popular. Instead of an audio coupler, we’re using Bluetooth to connect our PC to our phone line. Instead of custom hardware, our modem is comprised of some glue scripts and the software packages they connect – all running on a Linux PC.

The modem doesn’t provide an asynchronous full-duplex communication link like traditional modems. This modem’s operation is simpler: The sender’s modem dials the number of, and subsequently transmits a pre-prepared chunk of data to, the recipient’s modem. It then hangs up.

The modem uses Dual-tone multi-frequency (DTMF) signaling to encode the data it transmits. I chose DTMF because I was familiar with it and because Debian provides a package for Multimon. OKCrypto uses two utilities that Multimon provides:

1. gen – a DTMF generation utility (digits->wav file)
2. multimon – a DTMF detection utility (wav file->digits)

I’d been working on a few Bluetooth security projects at the time, so the Hands-Free Profile (HFP)³ came immediately to mind as a convenient way to transfer audio (and any data we’ve encoded in the audio) between a PC and a cell phone during a call.

-flickr size=”small” float=”right”-4153181752-/flickr-In most cases HFP is used to connect a a Bluetooth phone to a Bluetooth headset so that the headset can be used to make calls via the phone. See figure 2.

-flickr size=”small” float=”right”-4153181518-/flickr-In the PC world, HFP is typically used to connect a desktop computer to a bluetooth headset. See figure 3. In that configuration, the PC fulfills the first of two roles mandated by the HFP specification: the Audio Gateway (AG) role. The headset fulfills the hands-free (HF) role.

Support for the HF role in bluez, the Linux Bluetooth stack (pronounced “blue-zee”), is just now maturing⁴ so I went searching for a userspace implementation of the HFP protocol stack.

One of the best, chan_mobile, is distributed as an add-on to the popular open-source private branch exchange (PBX) Asterisk system. If you configure chan_mobile to use your cell phone, Asterisk can make both outbound calls and receive inbound calls with the phone.

Asterisk is the largest software component of the OKCrypto modem. It not only provides a reliable HFP HF role implementation which works with a wide array of modern phones (see above), but also many essential telephony operations:

1. Recording audio during a call. OKCrypto uses Asterisk’s built-in voicemail capabilities.
2. Transmitting audio during a call.
3. Pausing for a given time period.
4. Logging phone call details.

See figure 5 for an overview of the software components in the OKCrypto system. Note that the same software is used on both the sender and receiver’s PCs.

Let’s look at how we can use this modem to send a 16-byte binary file over a cellular voice connection.

First, the sender and recipient will need to perform some set-up steps:

1. 1. Acquire a Linux-supported computer and Bluetooth adapter. I found that using a virtual machine introduces latency that bluez/btusb cannot tolerate.
2. Acquire a HFP-capable cell phone.
3. Install Linux, SoX, Python, multimon, Asterisk, the Asterisk “add-ons”, GPG, and the OKCrypto scripts.
4. Pair cell phone with computer. Grant HFP access.
5. Configure chan_mobile
6. Start Asterisk Next, the sender can issue this command at a shell to send the file ‘/tmp/foo’ to the recipient at 585-555-3258.

   $ ./bin_to_int_seq.py /tmp/foo | ./ast_send.sh 5855553258 [...]
   $ cksum /tmp/foo 668417501 16 /tmp/foo

   She’ll notice her PC making a call with her phone, silently transmitting the data, and disconnecting. Behind the scenes, the OKCrypto scripts will…

7. Convert the bytes in /tmp/foo to a series of decimal digits.
8. Encode the digits as DTMF tones with gen from the multimon package. 1. Increase the pitch (time-independent) to prevent any intermediary systems (esp. Asterisk) from interpreting the tones.
9. Queue the final audio file for transmission by Asterisk.

The recipient will hear his phone ring once before his PC answers the call, records the audio, and disconnects. When the call is complete, Asterisk will invoke one of the OKCrypto scripts to…

1. Decrease the pitch to yield the original DTMF tones.
2. Decode the DTMF tones to a series of decimal digits.
3. Convert the digits to a series of bytes which is written to ‘/tmp/bar’.

   $ tr -d '\n' < /tmp/newest_vm.txt | ./int_seq_to_bin.py /tmp/bar [...]
   $ cksum /tmp/bar 668417501 16 /tmp/bar

Now that we can reliably send data, let’s make sure that it’s encrypted first. This turns out to be one of the simplest components of the system – many good crypto APIs are available.

I use GnuPG:

$ gpg --symmetric --force-mdc --cipher-algo AES256 filetoencrypt 

The `–force-mdc` option provides integrity checking – useful for handling transmission errors. Consider these GPG options carefully and make sure they fit your requirements.

Here are a few ideas we’re pursuing for the future of this project:

• Moving the modem code to the cell phone. This would simplify the setup but potentially risk security.
• Improving modem error rate. Data is often erroneously duplicated during transmission.
• Increasing the modem throughput. The current code averages a meager 10 bytes/second.
• Hiding the data within a steganographic channel in a normal voice conversation.
• Incorporating GPG into the OKCrypto scripts.
• Packaging the system as a LiveCD/Live flash drive.
• Implementing key exchange.
• Building an embedded device dedicated to OKCrypto.

I gained experience in the follow areas during the design, implementation. and testing:

• GSM, CDMA crypto. I suspect the cellular phone industry would make a great case study in protocol security by obscurity.
• Cellular voice codecs used by large carriers. Trivia: your calls only require ~10kbps.⁵
• Bluetooth HFP specification and available implementations.
• Debugging latency tolerances in virtual machine USB “passthrough” subsystems.
• The Twilio telephony API. I used Twilio when I only had one cell phone to debug with.
• Asterisk administration.

I’ve described a method to securely transmit data over any of the widely-available cell voice networks. The implementation requires only commodity hardware, open-source software, and minimal setup.

Be aware that transmitting data by “automated means” may violate the terms of your cellular service contract. I disclaim all liability. This information is provided for educational purposes only.

You can download the OKCrypto system here: http://www.unsyncopated.com/corral/okcrypto_v0.1.tar.gz

It is licensed under the LGPL.

• You’ll find lots of links to cell security architecture articles, Bluetooth HFP implementations, and Asterisk administration web pages on the wiki at Crypto Phone/Stacked Linux-based CPhone Brainstorming

Update 1/13/09 - Check out some technical notes on our recent progress with a faster and more reliable modem: OKCrypto/Progress Report for 01-09-2010

1. Open-Source Effort to Hack GSM John Blau – IEEE Spectrum Magazine – December 2009 issue
2. Subverting the security base of GSM Karsten Nohl – Hacking at Random – 8/15/2009
3. Bluetooth Hands-Free Profile (HFP) 1.5 – Bluetooth Special Interest Group – 11/25/2005
4. Comment #1 on Maemo bug #2754 – Johan Hedberg – 1/25/2009
5. Adaptive Multi-Rate audio codec – Wikipedia – 11/24/2009

Introduction

I’ve often wanted to securely send a message to someone who didn’t have a serious software package like GPG installed. Rather than ask them to install software they might not use ever again, I employed the scheme described below – it only requires a web browser with Javascript support.

Our friends Alice and Bob have agreed to help me illustrate this scheme for secure browser-based communications. Eve declined my invitation. She’s busy decrypting debian-vulnerable SSH sessions off the wire.

1. Alice points her browser to an SSL-secured web page (“https://foo.com/aes.html”) which contains a bit of HTML and an inline Javascript implementation of the AES encryption standard.
2. Alice uses the form on the web page to encrypt the secret message (“linux rulz”) with the password she chose (“thelegendofdrunkenmaster”). The encryption is performed locally – the secret message does not enter the network nor interact with any software besides the browser’s Javascript engine.
3. Alice sends the message encrypted message (“MGfrSbm5ubmqsnbYtoa9cgeYfA==”) to Bob via a second channel – e.g. by reading it to him over the telephone. Alice also gives Bob a hint about the password (“it’s the name of the movie we watched last week – without any spaces”).

1. Bob visits the same secured page with ”his” web browser. He types the encrypted message and the password into the form.
2. The decrypted message appears on his screen and he compliments Alice on her astute observation.

• The password “hint” should be chosen carefully. If it isn’t, a passive attacker (Eve, when she’s done submitting Valgrind “uninitialized data” warning reports to the Debian project¹ ) has a chance at brute-forcing the password. Substituting an ad-hoc “hint” system for well-designed key-exchange mechanisms should be done with caution!
• Alice and Bob should devote an entire browser instance to this task and ”only” to this task. They should close the browser and reboot after handling the decrypted message. If they don’t, malicious browser components, malicious websites, or OS paging could subvert their efforts by revealing the decrypted message to an attacker. I recommend that they use a browser that was ”designed” with security in mind.
• The webserver that serves the encryption/decryption page should be managed by a trusted party. If it isn’t, an active attacker could obtain the decrypted message. Barring port-forwarding and self-signed SSL key hassles, Alice herself could run a small webserver devoted to the purpose.
• Chris Veness’ Javascript emits Base64 encoded ciphertext. Base64′s default alphabet may lend itself to transcription errors if the telephone is chosen as a second channel e.g. “3″ is heard as “E”. In rare cases, this could go undetected by the decoding scheme’s error detection and result in the generation of incorrect plaintext e.g. “linux drulz”. For ”one” clever (ref: genetic algorithms!) solution to the transcription problem, see The PGP word list.

I’ve presented a scheme for secure communications between two parties where the only application software required is a Javascript-capable web browser and a SSL-capable web server.

Using a second channel and carefully-chosen password “hint”, this scheme allows access to high-grade cryptography with minimal “new software” requirements.

I began writing some code for this article in an Emacs scratch buffer. I then proceeded to accidentally kill the buffer before cutting its contents to my kill-ring.

I figured that maybe I could find the “lost” source code in Emacs’ heap so I forced a core dump with `killall –signal ABRT emacs`²³.

Next I tried to search for a snippet of the source code (the word “alice”) in the core dump with the `strings(1)` utility. The values for `CUR_ENC` are from the `strings(1)` manpage.

$ for CUR_ENC in s S b l B L; do strings --encoding \
${CUR_ENC} core | grep --ignore-case alice; done

$

No dice! If I had to guess, I’d say that Emacs uses some funky elisp mechanism for allocating memory for the contents of buffers, hence the failure of this naive `strings | grep` search. Suggestions welcome `;]`.

Update 5/12/09 – I should have tried hachoir-grep – it’s UNICODE-aware.

• A DailyDave discussion on sources of entropy is Javascript-land

1. Ooooooh. Twice in one blog post? I only do it because I love ya, Debian `:]`
2. I’d started emacs in a shell where I’d previously run `ulimit -c unlimited`, thus enabling core dumps. Dog help you if you haven’t done so and need a core dump.
3. Ubuntu disables `/dev/mem` (booooo hissss) IIRC so I didn’t try that route.

• You can earn money when people download your files via their affiliate program.
• Your audience can access your files via HTTPS.
• An honest dedication to free speech and free software.
• You can upload your files via FTP-over-explicit-SSL (FTPES). Their support page doesn’t list their FTPES host key fingerprint but you ”can” just barely see it at 0m36s on their FileZilla support page. Update: they’ve posted the fingerprint in their support forum. See my notes on uploading with lftp(1) for more info on securing your CLI FTP transactions.

Their servers are also hooked up to especially fat pipes. I get 5 megabytes/sec sustained with my Thinkpad T30′s wired NIC on RIT’s library network. I got 10 megabytes/sec with my Rimuhosting VPS in their Level(3) and Abovenet-connected datacenter.

I found good.net via a link in the McGrew Security blog to good.net’s mirror of DarkOz‘s giant collection of security conference videos – the “Hacker Media Archive”.

The Archive’s 25th Chaos Communication Congress (25C3) videos alone occupy nearly 40GB…

$ curl --silent http://avondale.good.net/dl/bd/25c3/video_h264_720x576/ |
awk --assign i=0 '/.mp4"/{i=i+substr($8, 1, length($8)-1);} END {print i}'

39175

In addition to the CCC videos, you can find footage and materials from DEFCON, HOPE, Black Hat, CodeCon, DeepSec, HITB, NOTACON, PhreakNIC, REcon, Shmoocon, and ToorCon. Phew!

1. If you’re looking for a more ”active” filesharing tool, one that syncs files across machines for you, try Dropbox as recommended by an aspiring grocer friend of mine. They’ve even got a Linux client.
2. Yes, the above manhole cover photo was taken by the Doc Searls of Linux Journal fame.

Having last attended Shmoocon in 2007, I was glad to see that all the things that made it great ”then” were still present for the 2009 installment:

• A close-knit community feel. The Shmoo Group’s prolific members are very active in the infosec community and appear to unite many disparate groups within it.
• The freedom to push the boundaries of free speech. I believe this freedom comes, in part, from an independent backing (as opposed to an overriding corporate interest).
• Affordable tickets.

There wasn’t enough reverse engineering content for my taste, but the low price and DC’s proximity more than make up for it.

During the conference I spent a fair amount of time reading other attendees’ Twitter feeds. I was impressed. It is honestly a decent alternative to an official ‘con IRC channel. I used it to find…

• The locations of unscheduled events (e.g. the Podcaster’s meetup)
• Feedback on nearby restaurants and BARZ.
• This photographic collection of entries to the “Barcode Shmarcode” competition wherein prizes were given to the most creative ticket barcode substitute.

It was also nice to see people discussing a presentation ”’as it happened”’ rather than hoping to be called upon during the short Q&A in meatspace¹.

If I succumb to ADD, I might start twittering sometime in the future. In the meantime, I’m keeping some notes on alternative (esp. open source) micro-blogging software.

A friend of mine wasn’t able to make it so I sold a ticket on eBay. After eBay/PayPal fees (~$20 all told) I lost about $30 on the deal. Anyways, for future reference, here’s how eBay looked on the day the conference began. As you can see, 34 of 47 listed auctions resulted in a sale between January 22nd and Feb 5th with an average selling price of ~$150.

As an aside, selling barcodes/UUIDs is apparently a violation of eBay’s TOS – they’re “intangible”.

For more on the economics of Shmoocon ticket sales look for a video of the ’0wn the con’ organizer-led presentation.

If you’re staying at the Wardman Park Marriott and you’ve got a hankering for a killer NY-style deli sandwich, you should take the 12-minute walk to So’s Your Mom in Adam’s Morgan. Buy your chips and drink at the natural foods store next door, though, to save a buck or two.

Here are some rough notes I took during Crispin Cowan‘s presentation on his transition from the Linux world to the Microso~1 world.

• Microsoft employs ”’entire compute farms”’ for the purpose of fuzzing their software.
• Some members of it’s security team are paid ”per discoverd bug”.
• In the early part of the decade Microsoft’s OS group stopped most of it’s design and coding work for a period of a few months to educate its engineers on the topic of secure coding. During this time, it “lost” $200 million dollars.
• A security prompt to the user is and unhandled security exception.
• Access control in X is very immature – apps can keylog others.
• Microsoft’s security department is roughly the size of the entire SUSE Linux company.

A beautiful, sunny day. Arrived just in time to learn about Matt Weir’s clever synthesis of dictionaries/rulesets and rainbow tables. At some point I should grab the source code and see if he’s optimized the OpenSSL MD5 code or used it verbatim as the freerainbowtables.com folks have.

After the conference wrapped up at 4ish, I walked from the Mariott, down scenic Connecticut Avenue to the Obama family’s new home. As I walked towards the capital, the Obamas returned from their first Camp David trip via three Marine helicopters². Finally, I walked past the hostel for a giant fish sandwich at Horace and Dickie’s, past the hostel again for an overpriced six-pack of Sam Adams, and then to the hostel to enjoy both with a new batch of folks at the hostel.

I was glad to see that ShmooCon directly and indirectly supports the following charities and non-profits:

• Deviant Ollum’s Travelling Terabyte Project – Sending suitcases of hard drives containing lots of multimedia to members of the armed services.
• The EFF
• The Covenant House

1. Yeah, I said it. “Meatspace”.
2. Part of a fleet that costs more than 11 billion dollars

I like this pace.

After a ham sandwich lunch, I listened to Jules Verne’s “Around the World in Eighty Days”¹ as recommended by John Udell in an insightful piece about trying to sip from the firehose.

The snow disappeared from the ground, but the air remained cold.

I’m staying at a $40 (woo woo) motel in Greenville Illinois tonight. 7hrs of driving remain.

Someone should make a radar detector with an integrated GPS receiver. This way, on your daily commute when you pass e.g. an “icy conditions” sign that causes a false alarm, you could press a “don’t alert me about radar in this location anymore” button. Even better, the device could allow you to download (user-submitted) “cops hide here” coordinates from the internet and warn you ”before” you drive into a suspected radar beam. For more road gadget ideas, check out this excellent story from Wired about a dude trying to cross the USA in under 32 hours: “The Pedal-to-the-Metal, Totally Illegal, Cross-Country Sprint for Glory”

It’d be nice to see a cell service coverage map overlaid on my GPS too.

Did you know that Exxon Mobil made more profit in 2007 than any other US company in 2007?

1. I’d later learn from Jessica that “Around the World in 80 Days” was made into a 2004 film starring Jackie Chan.

I plan to…

• Visit my sister and Jared in Tulsa.
• Check out a school and meet up with some folks in Denver.
• Potentially visit Sioux City and Omaha.
• Jet back to the east coast for Shmoocon 2009 in DC.
• Check in on some colleagues in the Constitution State¹.

Road tunes! Fy-Ah Fy-Ah: Bob Marley and the Wailers (disc 2 of 3). Bob Marley as you probably haven’t heard him before: rockin’ steady. Romance and praise for Jah layered over (traditionally Christian?) hymns are the dominant themes. Be sure to absorb the groovy bassline on “Back Out”.

There’s something surreal about listening to smooth Reggae while driving 50mph on an expressway in a whiteout, passing a snowplows throwing snow towards the median and sparks toward me.

The weather got real nasty so I stopped in Erie for a room in a La Quinta (free weefee, indoor pool, ”’hot”’ breakfast). The front desk dude tried to pull a fast one and charge me $60 for the room. “I’d like the $50 room from the [giant 30ft jumbotron] sign out front”. “Most people don’t want that room. It’s next to the vending machines… ” He paused. “Are you sure?”. “Yep”. He lightened up. “Yeah, I’d probably take that room too – easy access” he laughed.

By good fortune, an excellent Sergio Leone western was playing on AMC.

1. If you misspell “colleague” to Google, you might find some lolz (potentially NSFW)