Close
0%
0%

DRM-114

DEFCON 27 SAO project

Public Chat
Similar projects worth following
Starting from
$20.00
nsayer has 1376 orders / 122 reviews
Ships from Santa Clara, US
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 allows both public (broadcast) and private messages to be exchanged with other DRM-114 badges optically. It is entirely open hardware and almost open firmware (keep reading for why).

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

This is an SAO that adheres to the v1.69bis SAO standard and the host badge must provide the functionality of a dumb terminal over the two GPIO pins. The device has a traditional async serial terminal for user I/O and a second for the infrared port. The controller is the ATXMega32E5. Its XCL module is used for the UART dedicated to the IR I/O. The XCL modulates 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 goes to a MOSFET driven IR LED directly, and an IR receiver provides decoded (that is, the 36 kHz modulation removed) serial back. The IR receiver module is a "side look" version, and the IR LED is mounted on a right angle to direct the energy out the edge parallel to the receiver. In use, a user would hold the badge horizontally somewhat like a remote control.

The UART dedicated to the user terminal is line based and has a simple ">" prompt to start with. Three commands are 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 is taken as a message to transmit to the appropriate destination. The message is formatted with the target name and the message text and a new random message key is generated. The key is used to generate a CMAC over the plaintext, and then a random IV chosen and the plaintext and CMAC is encrypted. The key is then altered by the key protection method. The final message consists of the protected key, the IV and the ciphertext (which includes the CMAC).

The message is sent with a DLE type protocol. A start-of-frame is 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 always restarts reception when it receives a start-of-frame and submits the accumulated frame whenever it receives an end-of-frame (with some added protection against buffer overrun, of course).

Properly received messages are 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 when an "attention" message (either...

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

  • A walk through the protocol stack

    Nick Sayer04/24/2019 at 05:59 0 comments

    While it's not as rich as IP, you can still describe the DRM-114 optical protocol as a stack. Let's go through all the layers.

    Physical layer

    Of course, the physical layer is infrared light. The IR LED has a peak wavelength of 950 nm, and the receiver has it's peak sensitivity centered there too. The receiver is configured to output a "0" bit whenever it sees a 36 kHz IR square wave. It requires a minimum of 6 cycles to reliably detect a 0 bit. This means we could use a bit rate of 6 kilobaud, but I decided to make it 4800 baud "just because."

    Data link layer

    The framing is asynchronous serial 8N1 at 4800 baud - again, with the 0 bits being represented as 36 kHz pulses and 1 bits being no IR at all. With this signaling, the output of the detector will be the actual decoded serial data stream the controller's UART will be looking for.

    Packet layer

    Data packets start with the two-character sequence DLE STX. This frame start sequence is followed by all of the bytes of the frame until the end. If the DLE character is seen organically in the packet data, it is transmitted twice. After the last byte of the frame, the two-character sequence DLE ETX is sent. A frame can be a maximum size of 192 bytes (not including the start, end or DLE "escape" characters).

    Crypto layer

    A packet consists of 16 bytes of protected AES-128 key, followed by 16 bytes of IV and the ciphertext. The key is unprotected and is used with the IV and AES OFB mode to decrypt the ciphertext. The result is the plaintext message preceded by a 16 byte AES-CMAC over the plaintext using the same key as was used to decrypt the message. If the CMAC doesn't match the expected value, the message is discarded.

    Network layer

    Messages start with a single byte of message type, followed by the null-terminated name of the sender. Message types are 0 for broadcast message, 1 for directed message, 2 for broadcast attention and 3 for directed attention. If the message is directed, then the null-terminated source is followed by a null-terminated destination name. If the message is not an attention message, then the null-terminated message text is appended.

    That's it. The only part of the protocol that's undocumented is the key protection method. And I have no objection to anyone forking the source and supplying their own key protection method to make a working clone system, so long as their key protection method does not interoperate with DRM-114.

  • A walk through the UI

    Nick Sayer04/24/2019 at 05:29 0 comments

    DRM-114's actual functionality is sort of best described as "optical IRC."

    First, attempting anything with RF at DEFCON is an exercise in futility. The noise floor is so high there that anything worthwhile is damn near impossible. Even the conference WiFi is problematic. But IR optical networking should suck a whole lot less (whether it actually does or not... remains to be seen).

    So assume that you and a bunch of other folks equipped with DRM-114 and the appropriate dumb terminal are within optical range. Now what?

    First, the serial parameters are 115,200 baud, 8N1. The UI will mask off the high bit, so it's 7 bit ASCII only within those 8 bits.

    DRM-114 presents a simple prompt:

    >

    That prompt indicates that you are in broadcast message mode. Anything you type that doesn't start with a "/" will be sent as a broadcast message and any DRM-114 that manages to receive it without error will print out your name, a ":" and then your message.

    Speaking of name... you can change your name with "/n [name]". The badge comes with a default name set - "def_" and 4 hex digits (they're random and based on the controller's serial number, so they should be unique). You can use "/n" without an argument to find out what the current name is. You can change it to anything reasonable (up to 8 printable ASCII characters). There's nothing to prevent multiple users from using the same name. Directed (that is, non-broadcast) messages directed to a name will be received by any and all badges that have that name set.

    So how do you send a directed message? You use "/t [partner name]" to set the talk partner's name. If you do that, the prompt will change to 

    partner>

    to let you know that the lines you type (again, that don't start with /) will be sent only to that partner destination name.

    You can use "/t" by itself to revert to broadcast message mode.

    In addition to directed and broadcast text messages, there are also "attention" messages. You send them with "/a". An attention message can be directed or broadcast. It's a directed attention message if you have set a talk partner, and will only be seen by that named partner. If you don't have a talk partner set, then the attention message will be broadcast. An attention message causes the bright blue ATTN LED on the SAO to blink and the message

    "[so and so] wants attention!"

    to appear. That message is also accompanied by an ASCII BEL character, so if your terminal has BEL support, that'll happen too.

    IR networking being what it is, you may find that the occasional message is not properly received (gasp!). If this happens, the "/r" command can be used to repeat verbatim the last message (of whatever kind) was sent.

    /h or /? can be used at any time to get help.

    Goon special versions have additional functionality, but that's private for goons, so they'll have to figure it out on their own. The help text for goon versions lists the additional commands and should make it easy to figure out.

  • Easter Update

    Nick Sayer04/20/2019 at 16:54 0 comments

    Turns out, the manufacturer went ahead and made them black anyway. That's a nice bonus - I much prefer black to green. They're on their way back and should arrive Monday. I've updated the project gallery with a picture of an OSHPark board (the only difference is purple soldermask instead of black).

    The goon variants are all done. Their special firmware will not be open-source and it will be a goon-only super-set of functionality. The soldermask is goon-red and they will be sold for the same price, but only to goons.

    The only thing left when the manufactured boards arrive will be to add on all of the SAO connectors and program them.

    I also need to make up a bunch of "CnD" certificates just in case someone does succeed in reverse engineering the key protection algorithm.

  • 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.

View all 19 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