DRM-114

There were a bunch of ways you could approach the crypto portion of this project. I went with CMAC for authentication and AES OFB mode for encryption.

The big knock against OFB (so far as my research has led me to believe) is that it's possible to wind up with cycles, or weaknesses if you pick crappy IVs, but our CMAC PRNG ought to be good enough, and the messages we're using are going to be far too short for any risk of cycles. The upside is that I had a CMAC implementation already and OFB is both easy to implement, requires only ECB encryption mode, and is the same for both encryption and decryption.

Counter mode is a decent alternative to OFB, but it requires an extra encryption operation (to turn the IV into the base counter value), and - again - we're really splitting hairs considering the impracticality of the theoretical attacks on these relatively short messages.

GCM or CCM were also options to combine the authentication and encryption into one step, but in fact, the actual number of ECB operations required (which is the slow part) is comparable.

Keep in mind that none of this is the most viable attack on DRM-114. More applicable would be to attack the key protection mechanism. But, of course, that's illegal. So there.

Long story short, the power consumption of the badge should be less than 10 mA when the badge is not transmitting and perhaps as much as 30 mA when the IR LED is on.

Not bad.

I had envisioned using the IRCOM module of the XMega32E5, but it seems that that's designed for IRDA, which is much higher speed than the 36 kHz IR detector module I've sourced for the decode side.

But all is not lost - the XMega also allows you to use the XCL system as a codec for the serial port.

The goal is for the LED to be off when the serial output is mark (high) and for the LED to be modulated with a 36 kHz square wave when the serial output is space (low). So the magic for that is to configure the port D USART to invoke the XCL module on the TX side (the IR receiver will output proper TTL serial given this configuration of the transmitter).

The XCL module will apparently only actually do anything when the USART is actively transmitting something. So in order for the idle output to wind up being low, we have to invert the pin. Having done that the goal now is for the output to be high on mark and modulated on space.

The XCL module has an LUT (look-up table) and a timer we can configure to be a PWM source. The LUT has two inputs and one output and you program it with whatever truth table you want. The two inputs are the output from the USART and the PWM output of the timer. The output goes back to the USART to be the actual output. So the behavior we want is for the output to be 1 whenever the serial port's input is 1, and to echo the timer's PWM signal whenever the serial port is 0.

As for the timer, we set it to free-run with a divide-by-8 input from the system clock, and we set up a period of 111 and for a 50% duty cycle with a compare value of half that. 32 MHz divided by 8 and again by 111 is just slightly higher than 36 kHz.

So at this point, really what's left is the UI.

The firmware work has begun.

The AES code has been imported from an old branch of Orthrus. Layered on top of that is an AES based PRNG, CMAC and OFB mode.

Layered on top of that is the message cryptography. There's a method to create an encrypted version of the message, and one to decrypt and verify a message (returning a true or false depending on whether the message is valid or not).

The next job is to write the IR serial I/O functionality, and then the user interface.

The GitHub repo is linked in the project.

Of course, there's that one method that remains off-limits. Remember that reverse engineering the key protection method is a violation of title 17, section 1201 of US federal law.

There will be a special "goon" variant available, when the time comes. It will at least have different firmware. Whether it has a different board or not... I'm undecided. I have definite ideas about what the goon firmware will do differently... but you'll have to be a goon next year to find out.

I am going to preliminarily define the brand new "SAO++" connector. It's the exact same as the existing SAO, except that there are two more pins with asynchronous serial. The two new pins are numbers 5 and 6. 5 is TXD - data from the SAO into the badge. 6 is RXD - data from the badge into the SAO. Both signals must be LVTTL - 3.3v rather than 5v - and idle-high. Of course, it's up to the badge and SAO to agree on baud rate and data format.

EDIT: The actual SAOv1.69bis standard established the exact direction for the serial pins. Go figure. Pin 5 (aka GPIO 1) is RXD and pin 6 (GPIO 2) is TXD.

The hardware design is very, very straightforward.

The SAO++ connector is assumed to provide good 3.3v power and LVTTL serial I/O. There's a 10 µF filter/bypass cap on the input. That serial I/O will be connected to the port C serial port. That port will be configured to run at either 9600 or 115200 baud (TBD). The 100 Ω resistors are there to cut down a little bit on EMI and static sensitivity.

The serial port on port D is the infrared I/O port. The transmit data will directly switch the IR LED on and off (a MOSFET is used for more current capacity). The controller's IRCOM module will be configured to modulate the serial data at 36 kHz to match the receiver.

The receiver outputs demodulated data, so the receive pin in the controller will be configured for direct decoded input at the same baud rate.

There is a 16 MHz crystal for use as a clock source. Internally a PLL will double this to 32 MHz. The crystal insures the divided clock for the serial I/O is more stable than the internal RC oscillator and FLL would be.

And that's it. The vast majority of this project is in the firmware.

It turns out that the first iteration of the hardware meets the criteria for the Return Of the Square Inch contest!

This may be cheating just a touch. It depends on your point of view. What I refer to is the need to connect the board up to some sort of dumb terminal to actually get it to work. But when has that ever stopped anyone?

I'm going to add the requisite files for the first version to the files section of the project. There's still plenty of time before the contest closes to make sure it actually works.

Of course, since we're leaning on the idea that the base badge would supply us with a dumb terminal, then it's pretty darned simple to use an ordinary FTDI style USB UART adapter / cable to do the development (provided you get one that's 3.3v). My own FTDI-be-gone will do nicely.

Let me just make this perfectly clear for everyone: The purpose of this project is to poke fun at / protest section 1201 of the DMCA. There will be a lot of implied threats of legal action or other persecution for folks who "dare" to attempt to reverse engineer the private method. I promise, these will not be real - they will all be in fun. Hopefully references to the law firm of "Dewey, Cheetam and Howe" will make that more obvious as we go. Don't worry - I'm secretly on the right side here. :)