Close
0%
0%

DRM-114

DEFCON 27 SAO project

Public Chat
Similar projects worth following
DRM-114 is going to be an SAO for DEFCON 2019. It's purpose will be to be a secure IR communications system, with the security of the communications guaranteed by section 1201 of the Digital Millennium Copyright Act.

DRM-114 will allow both public (broadcast) and private messages to be exchanged with other DRM-114 badges optically. It will be entirely open hardware and almost open firmware (keep reading for why).

The messages will be encrypted with AES-128, with a (pseudo-)randomly chosen key for every message. The key will be sent along with the message, but the key will be protected with a proprietary key protection algorithm that will not be open-sourced. The key protection mechanism will be a trade secret and will act as an "effective access control mechanism" as defined by the DMCA, and thus reverse-engineering it will be a violation of US Federal law. The entire project's source code (including a software AES ECB, OFB and CMAC implementation) will be open-sourced, with the sole exception of the file that provides the key protection function.

This will be an SAO and the host badge would need to provide the functionality of a dumb terminal. The device will have a traditional async serial terminal for user I/O and the infrared port. The controller will be the ATXMega32E5. Its XCL module will be used for the UART dedicated to the IR I/O. The XCL will modulate the serial output with a 36 kHz square wave (so a 0 is represented by 36 kHz pulses and a 1 is represented by the LED being off). The IR UART output will go to a MOSFET driven IR LED directly, and an IR receiver will provide decoded (that is, the 36 kHz modulation removed) serial back. The IR receiver module will be a "side look" version, and the IR LED will mounted on a right angle to direct the energy out the edge parallel to the receiver. In use, a user would hold a badge horizontally somewhat like a remote control.

The UART dedicated to the user terminal will be line based and have a simple ">" prompt to start with. Three commands would be recognized, each starting with "/" (somewhat like IRC of old). "/name name" sets the name of the badge for receiving private messages (nothing will be done to prevent multiple badges having the same private name and receiving the same messages). "/talk name" sets the destination badge name and will change the prompt to "name>" "/talk" by itself reverts to the broadcast message mode (to all badges). "/help" or "/?" prints out help. Any other line of text will be taken as a message to transmit to the appropriate destination. The message will be formatted with the target name and the message text and a new random message key will be generated. The key will be used to generate a CMAC over the plaintext, and then a random IV chosen and the plaintext and CMAC will be encrypted. The key will then be altered by the key protection method. The final message will consist of the protected key, the IV and the ciphertext.

The message will be sent with a DLE type protocol. A start-of-frame will be sent, followed by the message and an end-of-frame. Both the start and end byte-pairs start with the same introduction byte. If that byte appears organically in the message it is repeated. The receiver will always restart reception when it receives a start-of-frame and will submit the accumulated frame whenever it receives an end-of-frame (with some added protection against buffer overrun, of course).

Properly received messages will be displayed by sending a carriage return (without a linefeed), then printing the message and then a CR-LF and then re-printing the command prompt and any text already entered.

For best range, the IR LED needs about 80 mA of current. This seems like a lot, but remember that it's modulated with a 36 kHz square wave, so the duty cycle is at most 50% when it's sending a 0 bit and the pulses are quite short (13 µs). But because the current draw is so high, we can't directly drive it from the controller. So an N channel MOSFET is used as a low-side switch (this allows the controller logic to be positive - high for LED on). The badge also sports a visible LED, which is blinked...

Read more »

Adobe Portable Document Format - 39.66 kB - 03/15/2019 at 23:10

Preview
Download

sch - 251.34 kB - 03/15/2019 at 23:10

See BOM
Download

brd - 60.26 kB - 03/15/2019 at 23:10

Download

  • 1 × ATXmega32E5 Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × 16 MHz 3.2x2.5mm crystal
  • 1 × 10 µF 0805 cap
  • 1 × 150 Ω 0805 resistor
  • 1 × 0805 (visible) LED - color arbitrary

View all 14 components

  • More little fix-ups

    Nick Sayer03/19/2019 at 20:01 0 comments

    I've ordered the goon boards. They're going to get red soldermask and special Goon firmware but otherwise be the same. I'm going to build those myself because it's going to be a relatively small number of boards.

    The rest of them are going to be green because apparently black is harder for the fab to do small aperture openings in, which impacts the QFN footprint.

    I'm also going to make a few "fake badge" USB UART boards so those who don't get a dumb badge will be able to talk to (and play with) DRM-114.

    I've learned how to use the XMega lock bits so that folks won't be able to simply use PDI to rip the firmware out and decompile it to learn The Secret.

    All in all, this project is ahead of schedule at the moment.

  • v3.0

    Nick Sayer03/02/2019 at 20:49 0 comments

    I've decided to rev the hardware to move the attention LED pin to D7 to free up C0 and C1 for i2c, and connect the i2c pins up to the SAO connector.

    I'm not sure what DRM-114 might do with i2c, but it's certainly better to have the option to do something.

  • v2.0

    Nick Sayer03/01/2019 at 19:18 0 comments

    I've decided to try a version 2.0, which simply replaces the TQFP XMega with a UQFN (5mm) variant. It winds up being a slightly smaller board, but also just looks a little cleaner and more impressive.

    I'm getting a prototype run done first, and if it succeeds, then that will be what's manufactured for DEFCON.

    I'm also going to change the firmware to pick a random name if none is set (just so everyone isn't "default"), and to save the name to EEPROM so it can be preserved across power-cycling.

  • SAO it is

    Nick Sayer02/14/2019 at 05:12 0 comments

    SAO V2 is a thing now, and it's for certain that DRM-114 will be an SAO. It's intended to be paired with the VT69 badge, aka the Dumb Badge.

    The only thing left is to figure out the final form factor and... I dunno... art?

    I kinda hate doing the art part. I'm all about function over form. Sigh.

  • LED experiments

    Nick Sayer09/02/2018 at 01:50 0 comments

    So with the current 68 Ω series resistor, I tried the two newer LED options. With the higher power surface mount emitter and the light pipe, the range improved from about 5 to perhaps 8 feet, but with the through-hole emitter, I got pretty reliable reception at 25 feet. I feel like reducing the series resistance down to 20 Ω will make the whole thing reliable at up to 30 feet, which I think will be good enough to score.

    I'll try next when the v1.1 boards show up with the through-hole pads. I think, at least from an electrical perspective, that that's going to be the final design. Aesthetically, I am not sure, but we have at least 8 months to ponder that one.

  • Range not so good

    Nick Sayer08/30/2018 at 02:28 0 comments

    The range at the moment is about 6 feet.

    It didn't really improve even by cutting the series resistor for the LED in half.

    Something must be done.

    I currently have an XZTNI54W IR emitter, which has a spec of something like 2 mW/sr. My guess is that that's not enough. Switching to a VSMY1940X01 and dropping the series resistor down to 20 Ω or so should crank out more like 10 mW/sr, from what I can tell from the datasheet. Time will tell.

    EDIT: Huh. Through-hole emitters can be had that will do more like 500 mW/sr. I'll have to give them a try.

  • And it works

    Nick Sayer08/30/2018 at 01:05 0 comments

    The hardware and firmware work. At least from a few inches away. Next is range testing. I have reasonably high hopes.

  • Defending the crypto

    Nick Sayer08/28/2018 at 03:24 0 comments

    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.

  • Power consumption

    Nick Sayer08/27/2018 at 14:31 0 comments

    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.

  • Optical output good

    Nick Sayer08/27/2018 at 00:43 0 comments

    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.

View all 16 project logs

Enjoy this project?

Share

Discussions

Gravis wrote 03/20/2019 at 05:42 point

The DMCA has exemptions for education, so if someone simply wants to know how it works and then publish their findings then it's legal.

  Are you sure? yes | no

Nick Sayer wrote 03/20/2019 at 14:09 point

I don’t recall anyone ever successfully using such a strategy to document an access control mechanism.

Anyone trying this at DEFCON with DRM-114 will still get a cease-and-desist. 😁

  Are you sure? yes | no

Gravis wrote 03/21/2019 at 02:14 point

If you need the law to protect your secrets then it won't stay secret very long.

  Are you sure? yes | no

Nick Sayer wrote 03/21/2019 at 02:16 point

@Gravis, I'm not *entirely* sure you're seeing the irony here.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates