Humidity Sensor Shootout

January 3, 2017 by Elliot Williams 39 Comments

If you want to measure humidity (and temperature, and maybe even barometric pressure) in a device that you’re building, have a look at this comprehensive test of seven different options. We’re going to summarize the results here, but you’ll really want to read up on the testing methodology — it’s great science hacking. Did you know about using saturated salt solutions to produce constant humidity levels for calibration? We didn’t.

The eBay hacker favorite, the so-called DHT22 module, doesn’t fare all that well, with one of six that [Robert] tested being basically horrible, and three of them breaking within two years of use. The one that works well, however, is pretty good. Feeling lucky?

The Bosch BME280 looks great. It costs a bit more as a bare part, and a few times more than that when it is mounted on a friendly module, but it seems to be very reliable. And you get a barometer thrown in for the extra work. Indeed, it performed so well that Hackaday contributor [Nava Whiteford] put the part under a scanning electron microscope to figure out what’s going on.

The other sensors were fine, with the HTU21D and SHT71 being standouts for their ultra-fast response. For the full details, go click on that link at the top. Having just installed a sextet of DHT22s in our house last year, we’re left with that sinking feeling that we may have gotten what we paid for, which wasn’t much. At least they’re all still running.

Thanks to [Dodutils] and [mac012345] via comments in another thread.

OWL Insecure Internet Of Energy Monitors

January 2, 2017 by Elliot Williams 25 Comments

[Chet] bought an electricity monitor from OWL, specifically because it was open and easy to hack on at him within the confines of his home network. Yay! Unfortunately, it also appears to be easy to ~~hack~~ read outside of his home network too, due to what appears to be extraordinarily sloppy security practices.

The short version of the security vulnerability is that the OWL energy monitors seem to be sending out their data to servers at OWL, and this data is then accessible over plain HTTP (not HTTPS) and with the following API: http://beta.owlintuition.com/api/electricity/history_overview.php?user=&nowl=&clientdate=. Not so bad, right? They are requiring username and password, plus the ID number of the device. Maybe someone could intercept your request and read your meter remotely, because it’s not encrypting the transaction?

Nope. Much worse. [Chet] discovered that the username and password fields appear not to be checked, and the ID number is the device’s MAC address which makes is very easy to guess at other device IDs. [Chet] tried 256 MACs out, and got 122 responses with valid data. Oh my!

Take this as a friendly reminder and a cautionary tale. If you’re running any IoT devices, it’s probably worth listening to what they’re saying and noting to whom they’re saying it, because every time you send your data off to “the cloud” you’re trusting someone else to have done their homework. It is not a given that they will have.

Tiny Game Of Simon On An ATtiny13

December 31, 2016 by Elliot Williams 13 Comments

How much game can you get out of a chip with only 1 kB of flash memory and (five or) six free GPIOs? Well, you can get it to play the classic memory game, Simon. [Vojtak] is submitting this project for the 1 kB Challenge, but it looks like it’s already been used to teach simple microcontrollering to teenagers as well, so the code is actually straightforward to read, but full of nice features.

Neat tricks include sharing button-press sensing and LED driving on the same pin, which was necessary to make everything work on such a small chip. A simple linear-congruential pseudorandom sequence provides the variation, and it’s seeded by slow-clock/fast-clock timing jitter, so you’re probably not going to see the same sequence twice. (It’s not the best random number generator ever, but it’ll do.) If that weren’t enough, high scores (and the random seed for the game) are saved to EEPROM so that you can brag to your friends or re-live your previous moments of glory.

The board is easily solderable together as well. This is a fantastic beginner project, with details in the code that everyone can learn from. It’s a great game, and a great demonstration of what you can do with a dollar’s worth of parts and 1 kB of code.

Continue reading “Tiny Game Of Simon On An ATtiny13” →

33C3: Works For Me

December 30, 2016 by Elliot Williams 20 Comments

The Chaos Communication Congress (CCC) is the largest German hacker convention by a wide margin, and it’s now in its thirty-third year, hence 33C3. The Congress is a techno-utopian-anarchist-rave with a social conscience and a strong underpinning of straight-up hacking. In short, there’s something for everyone, and that’s partly because a CCC is like a hacker Rorschach test: everyone brings what they want to the CCC, figuratively and literally. Somehow the contributions of 12,000 people all hang together, more or less. The first “C” does stand for chaos, after all.

What brings these disparate types to Hamburg are the intersections in the Venn diagrams. Social activists who may actually be subject to state surveillance are just as interested in secure messaging as the paranoid security geek or the hardcore crypto nerd who’s just in it for the algorithms. Technology, and how we use it to communicate and organize society, is a pretty broad topic. Blinking lights also seem to be in the intersection. But on top of that, we are all geeks. There’s a lot of skill, smarts, and know-how here, and geeks like sharing, teaching, and showing off their crazy creations.

Continue reading “33C3: Works For Me” →

33C3: If You Can’t Trust Your Computer, Who Can You Trust?

December 29, 2016 by Elliot Williams 47 Comments

It’s a sign of the times: the first day of the 33rd Chaos Communications Congress (33C3) included two talks related to assuring that your own computer wasn’t being turned against you. The two talks are respectively practical and idealistic, realizable today and a work that’s still in the idea stage.

In the first talk, [Trammell Hudson] presented his Heads open-source firmware bootloader and minimal Linux for laptops and servers. The name is a gag: the Tails Linux distribution lets you operate without leaving any trace, while Heads lets you run a system that you can be reasonably sure is secure.

It uses coreboot, kexec, and QubesOS, cutting off BIOS-based hacking tools at the root. If you’re worried about sketchy BIOS rootkits, this is a solution. (And if you think that this is paranoia, you haven’t been following the news in the last few years, and probably need to watch this talk.) [Trammell]’s Heads distribution is a collection of the best tools currently available, and it’s something you can do now, although it’s not going to be easy.

Carrying out the ideas fleshed out in the second talk is even harder — in fact, impossible at the moment. But that’s not to say that it’s not a neat idea. [Jaseg] starts out with the premise that the CPU itself is not to be trusted. Again, this is sadly not so far-fetched these days. Non-open blobs of firmware abound, and if you’re really concerned with the privacy of your communications, you don’t want the CPU (or Intel’s management engine) to get its hands on your plaintext.

[Jaseg]’s solution is to interpose a device, probably made with a reasonably powerful FPGA and running open-source, inspectable code, between the CPU and the screen and keyboard. For critical text, like e-mail for example, the CPU will deal only in ciphertext. The FPGA, via graphics cues, will know which region of the screen is to be decrypted, and will send the plaintext out to the screen directly. Unless someone’s physically between the FPGA and your screen or keyboard, this should be unsniffable.

As with all early-stage ideas, the devil will be in the details here. It’s not yet worked out how to know when the keyboard needs to be encoded before passing the keystrokes on to the CPU, for instance. But the idea is very interesting, and places the trust boundary about as close to the user as possible, at input and output.

33C3: Understanding Mobile Messaging And Its Security

December 28, 2016 by Elliot Williams 17 Comments

If you had to explain why you use one mobile messaging service over another to your grandmother, would you be able to? Does she even care about forward secrecy or the difference between a private and public key is? Maybe she would if she understood the issues in relation to “normal” human experiences: holding secret discussions behind closed doors and sending letters wrapped in envelopes.

Or maybe your grandmother is the type who’d like to completely re-implement the messaging service herself, open source and verifiably secure. Whichever grandma you’ve got, she should watch [Roland Schilling] and [Frieder Steinmetz]’s talk where they give both a great introduction into what you might want out of a secure messaging system, and then review what they found while tearing apart Threema, a mobile messaging service that’s popular in Germany. Check out the slides (PDF). And if that’s not enough, they provided the code to back it up: an open workalike of the messaging service itself.

This talk makes a great introduction, by counterexample, to the way that other messaging applications work. The messaging service is always in the middle of a discussion, and whether they’re collecting metadata about you and your conversations to use for their own marketing purposes (“Hiya, Whatsapp!”) or not, it’s good to see how a counterexample could function.

The best quote from the talk? “Cryptography is rarely, if ever, the solution to a security problem. Cryptography is a translation mechanism, usually converting a communications security problem into a key management problem.” Any channel can be made secure if all parties have enough key material. The implementation details of getting those keys around, making sure that the right people have the right keys, and so on, are the details in which the devil lives. But these details matter, and as mobile messaging is a part of everyday life, it’s important that the workings are transparently presented to the users. This talk does a great job on the demystification front.

33C3: Breaking IoT Locks

December 28, 2016 by Elliot Williams 16 Comments

Fast-forward to the end of the talk, and you’ll hear someone in the audience ask [Ray] “Are there any Bluetooth locks that you can recommend?” and he gets to answer “nope, not really.” (If this counts as a spoiler for a talk about the security of three IoT locks at a hacker conference, you need to get out more.)

Unlocking a padlock with your cellphone isn’t as crazy as it sounds. The promise of Internet-enabled locks is that they can allow people one-time use or limited access to physical spaces, as easily as sending them an e-mail. Unfortunately, it also opens up additional attack surfaces. Lock making goes from being a skill that involves clever mechanical design and metallurgy, to encryption and secure protocols.

In this fun talk, [Ray] looks at three “IoT” locks. One, he throws out on mechanical grounds once he’s gotten it open — it’s a $100 lock that’s as easily shimmable as that $4 padlock on your gym locker. The other, a Master lock, has a new version of a 2012 vulnerability that [Ray] pointed out to Master: if you move a magnet around the outside the lock, it actuates the motor within, unlocking it. The third, made by Kickstarter company Noke, was at least physically secure, but fell prey to an insecure key exchange protocol.

Along the way, you’ll get some advice on how to quickly and easily audit your own IoT devices. That’s worth the price of admission even if you like your keys made out of metal instead of bits. And one of the more refreshing points, given the hype of some IoT security talks these days, was the nuanced approach that [Ray] took toward what counts as a security problem because it’s exploitable by someone else, rather than vectors that are only “exploitable” by the device’s owner. We like to think of those as customization options.