After playing around with a custom DEF CON badge, I wanted to do another electronics project just for fun. What better time to share electronics with others than Christmas? So I decided to do a custom ornament for friends and family.
Though it shared some characteristics with my DEF CON badge (blinken lights, battery powered, etc.), the similarities ended there. In this case I want something lightweight (it’s going on a tree branch), simple (the XXV badges took a long time to assemble by hand), and that could run off a coin cell battery for days.
Not being the most artistic of individuals, I went with a simple snowflake design and 6 LEDs at the points. At first, I wanted to do white LEDs, but since they have a forward voltage around 3.2V, that wouldn’t work well with a single 3V coin cell, so I settled for 1.8V Red LEDs. (The battery will be unable to produce much current at all long before it reaches 1.8V.)
The ornament base is a red soldermask PCB with gold-plated (ENIG) copper. The boards were produced at Elecrow and I hand assembled the parts. The microcontroller is the ATTiny2313A, chosen both for low power consumption and low cost. (Driving 6 LEDs doesn’t take much in the way of CPU.) I chose not to use the ATTiny25/45/85 series because I didn’t want to deal with multiplexing pins to drive the LEDs and in-circuit programming (ICSP) header.
The schematic is pretty straight forward. There’s a battery holder and a couple of power supply capacitors (due to PWM of the lights, I didn’t want the input voltage bouncing around too much), the microcontroller, a single resistor network, and the 6 LEDs which are on the front of the board. The full bill of materials includes:
1
2
3
4
5
6
7
8
9
Label Description
---------------------------------------------------------------
BT1 20mm SMD Coin Cell Holder
C1 0.1uF Ceramic Capacitor (0805)
C2 10uF Ceramic Capacitor (0805)
U1 ATTiny2313A (QFN20)
RN1 Resistor Network, 8 Independent, 100 Ohm Each
D1-D6 Red SMD LED (0805)
J1 2x3 Header, SMD, 2.54mm Spacing (AVR ICSP)
On the actual ornaments, the ICSP header is unpopulated – I manually held a connector to it to program each one. I left the connector in a standard format instead of a pogo pin arrangement in case any of my recipients wanted to hack on the firmware. (Since it’s Open Source.)
It was a fun little project and I’m already considering how I can improve for a new one next year. Full schematics, design files, and source code are on Github.
Vulnerabilities were identified in the iStar Ultra & IP-ACM boards offered by Software House. This system is used to control physical access to resources based on RFID-based badge readers. Badge readers interface with the IP-ACM board, which uses TCP/IP to communicate with the iStar Ultra controller.
These were discovered during a black box assessment and therefore the vulnerability list should not be considered exhaustive; observations suggest that it is likely that further vulnerabilities exist. It is strongly recommended that Software House undertake a full whitebox security assessment of this application. Additionally, it is our suggestion that all communications be conducted over TLS. While alternatives are suggested below, cryptography is very difficult even for experts, and so using a well-understood cryptosystem like TLS is preferable to home-grown solutions. The version under test was indicated as: 6.5.2.20569. As of the time of disclosure, the issues remain unfixed.
The communications between the IP-ACM and the iStar Ultra is encrypted using a fixed AES key and IV. Each message is encrypted in CBC mode and restarts with the fixed IV, leading to replay attacks of entire messages. There is no authentication of messages beyond the use of the fixed AES key, so message forgery is also possible. A working proof of concept has been demonstrated that allows an attacker with access to the IP network used by the IP-ACM and iStar Ultra to unlock doors connected to the IP-ACM. (This PoC will not be disclosed at this time, due to the issue remaining unfixed.)
An attacker with access to the network can unlock doors without generating any log entry of the door unlock. An attacker can also prevent legitimate unlock attempts. Organizations using these devices should ensure that the network used for IP-ACM to iStar Ultra communications is not accessible to potential attackers.
These issues were discovered by David Tomaschik of the Google Security Team.