There’s been a lot of controversy over the White House Press Secretary using a potentially-doctored video to justify banning CNN journalist Jim Acosta from the White House, with the Associated Press, Buzzfeed, Motherboard, and an endless cavalcade of Twitter users weighing in. Too much of it is wrong. Let’s recreate all the odd video artifacts for ourselves, starting from the unmodified source, and talk about what this means.
For some time GPG has supported storing the private keys you use to sign and decrypt e-mails and log in to servers over SSH on a secure smartcard or USB token. This protects them from being copied even if your SSH client has a really nasty bug but unfortunately, the tokens and cards are expensive, opaque proprietary things.
There’s one exception: Niibe Yutaka of the Free Software Initiative of Japan created an open source firmware called Gnuk that’s runs on a widely-available ARM microcontroller and is mostly compatible with the official OpenPGP card. You can even run it on cheap $4 Maple Mini clones that are widely available on sites like AliExpress. Of course you should bear in mind the warning about homebrew crypto in my previous post, though Gnuk seems far better designed and written than that code.
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 »
My Motorola S9 Bluetooth headset had getting a bit long in the tooth and wasn’t lasting very long between charges – time to replace the battery! Too bad that it’s got a non-replaceable battery, but since when has that ever stopped me? (Maybe it should have. Spoiler warning: it was a nightmare.)
Continue reading »
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 »
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 www.smartchips.co.uk” 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 »
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 »
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 vlc.py here. (For some reason, the diff for vlc.py is horribly messy; dunno why.)
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.
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 »