Nov 102015

A while ago, Google created a two-factor authentication scheme called U2F. The general idea is as follows. You have a little USB dongle that you can register with sites. When you enable U2F on a site, the dongle gives that site a public key and a key handle, and that dongle is the only device that can use that key handle to sign things with the corresponding public key. So from then on, websites can hand over the key handle and a challenge, and if they get back a valid signature they know that whoever’s logging in has the dongle you used to sign up.

A few days ago, someone released a U2F implementation based on a Teensy microcontroller and it made Hackaday – and they added a disclaimer warning that doing anything related to crypto by yourself is a bad idea and that using XOR encryption for the key handle is insecure. There was a bit of a pushback against this in the comments. After all, so reasoned the Hackday commenters, security isn’t that hard and XOR isn’t a big deal, right? Surely this warning is just insulting, gratuitous negativity from the Hackaday editors.

Spoiler alert: XOR is in fact horribly insecure in this application, and this code is broken and should not be used by anyone.
Continue reading »

 Posted by at 6:44 pm
Oct 062011

I recently bought a DE0-nano FPGA development board, which I’m currently using to mine Bitcoins. It’s kind of a neat board, but one downside to it is that it uses linear regulators to provide the 1.2V core supply to the FPGA, and they’re incredibly inefficient at this. Only about 25% of the power supplied to them actually goes into the 1.2V supply; the other 75% is wasted as heat in the regulators. Since Bitcoin mining is very power-hungry, an awful lot of the power usage is in the 1.2V core supply and the regulators get really hot.

Fortunately, it’s possible to mod the board to use a more efficient external buck regulator to supply the 1.2 volts required by the FPGA core logic. (In theory this should even allow USB-powered mining; in practice this doesn’t seem to work for some reason.)
Continue reading »

 Posted by at 8:16 pm
Apr 132011

A while back, I picked up a bunch of 4 assorted smartcard programmers off eBay. A CLaNZeRS Phoenix/Smartmouse version 2.1 with at least one bad solder joint and no crystal in its socket, a CLaNZeRS MCESDK that requires Windows-only software, something with “TITANIUM” on the bottom that appears to be for PICs, and the aforementioned Zeus programmer.

Of them, the Zeus seems to be the nicest from my point of view. There are two catches though: it requires a 15-18V center-positive power source and my regulated PSU tops out at 12V, and mine seems to have a 6MHz oscillator installed rather than the usual frequency (yours may vary). Oh, and documentation is severly lacking.
Continue reading »

 Posted by at 4:47 pm
Mar 152011

OK, didn’t post as many things as I’d have liked, partly because they required masses of cleanup and partly because I finally figured out an easy way to do something I’d been puzzling over for a while: encrypted webcam chat. (Your definition of “easy” may vary.)

What does it do?
It allows two people with webcams to conduct a secure video chat with each other, complete with audio. The connection is encrypted, authenticated with a shared secret so you know you’re connected to the right person, and in theory has perfect forward secrecy.

What’s the catch? Continue reading »

 Posted by at 5:49 pm
Feb 282011

I’ve been having a fun time trying to use VLC’s official Python bindings on 64-bit Linux, and by “fun” I really mean “swearing as pointers get truncated to 32 bits and my app segfaults”. Anyway, turns out the bindings are broken. They make use of a ctypes (mis?)feature that allows you to pass a Python callable as the return type of your function and have ctypes call that function with the actual value and return the result. This is used to make various libvlc_*_new functions wrap the pointer they return in an appropriate Python class.

Unfortunately, there’s a catch. As the docs say, “You can also use a callable Python object (a function or a class for example) as the restype attribute, if the foreign function returns an integer. The callable will be called with the integer the C function returns, and the result of this call will be used as the result of your function call.” A pointer is not an integer, and on 64-bit systems doesn’t fit into one. Worse still, there doesn’t seem to be a way of changing this behaviour – this bad assumption is baked into the lowest layers of ctypes.

Edit: Have managed to fix this issue and put a GIT repository up. You can download the generated here. (For some reason, the diff for is horribly messy; dunno why.)

 Posted by at 12:22 pm
Feb 252011

Hmmmm. Kinda got distracted and didn’t post as much as I should’ve. Anyway, the next thing is an ISO-7816 smartcard interface based on the Arduino.

What is it?
This Arduino sketch lets you talk to some ISO-7816 smartcards that use the T=0 protocol at the usual baudrate and with the direct convention – in other words, quite a lot of them. In particular, it lets you speak to smartcards you’ve developed yourself using the open source SOSSE framework. It uses the same pinout as the Funcard programmer, so you can use the same hardware to program the cards with SOSSE as you do to communicate with them.

What’s the catch?
It only supports the T=0 protocol with direct convention, and only at one particular baud rate. It uses interrupts and timers in a very low-level way, which also means that you can’t easily change what pin is used for what. The protocol it uses to speak to the computer is oddball, and you need to write your own software to understand it… for now. It has very little intelligence, leaving the host PC to do most of the work.

Where do I get it from?
You can download it from here for now.

 Posted by at 7:50 pm
Feb 222011

What is it?
Cajeput’s the server end of a virtual world, written in C++ and intended to be vaguely compatible with OpenSim (which makes it a clone of a clone of Second Life). It’s actually surprisingly lightweight, especially compared to OpenSim!

What’s the catch?
Basically, it’s horribly unfinished. There’s a whole bunch of stuff that’s just not implemented yet or is incomplete. It’s also meant to be usable with the OpenSim grid servers (because on its own, it can only run as a standalone install running on a single server), but this doesn’t work anymore due to OpenSim changes. Finally, it’s horribly undocumented and a bit of a pain to set up.

I don’t care about that, how do I get it?
Continue reading »

 Posted by at 6:35 pm
Feb 212011

Not blogged much lately. However, there’s a whole bunch of stuff I’ve been up to that hasn’t been in any suitable condition to make public or that I just plain haven’t got around to yet. (Well, one or two thing, anyway.) It’s about time they got blogged, and that’s exactly what I’m going to do over the next week or so. First up is Cajeput.

 Posted by at 5:22 pm
Mar 172010

There’s an interesting issue in SOSSE that prevents it from running right on some Atmega163-based smartcards if you just make the obvious changes to port it. The usual symptom is that the card ATRs correctly, but won’t listen to any commands.

Most of these cards connect the smartcard’s IO pin to both the normal pin PB6 and to an additional pin which SOSSE doesn’t use. SOSSE configures all the pins it doesn’t use as outputs and sets them HIGH during the startup code. This results in an additional and unwanted strong pull-up to Vcc on the IO pin, which prevents most smartcard readers from being able to pull it low and actually talk to the card.

The easy solution: open hal.c, find the lines that read:



and change the 0xFFs to 0x00s in these lines. Will upload a patch and link it from this post when I get around to it.

Uploaded the patch here. It also fixes some compilation issues on newer avr-libc versions

 Posted by at 11:57 am