0x05ECure - Cryptography over BLE

So, bummer. I've been lucky enough to bring a truly talented cofounder on board and she's pointed out that people 'aint going to want to carry this thing around ... so we're knocking this on the head.

The good news is one of the reasons is there's a good *enough* messaging app called Telegram (http://telegram.org/). If you want security - use that.

I'm not dead, I just got pissy when failing to get to the next round of the Hackaday prize. Oh well.

Development continues ... some projects have been made, explored, and ultimately thrown in the bin although I feel like I'm now on the right track (https://github.com/RantyDave/oxo) where the golden knowledge is really the links to the Nordic team in mbed (http://mbed.org/teams/Nordic-Semiconductor/code/nRF51822/) and the Bluetooth team (http://mbed.org/teams/Bluetooth-Low-Energy/code/BLE_API/). I *had* a fix for them but someone got to it before I did :)

My impressedness with mbed continues and I think long term it deserves to be embraced more thoroughly. I hadn't realised it's formally backed by ARM, although I wonder about whether or not ARM should be doing this *and* the CMSIS thing (http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php). As far as I can tell CMSIS is more "pro" level (not that I've found anything particularly wrong with mbed) and I suspect C only.

Speaking of which, as you might've gathered my attempts to embrace ye-olde C-e have not gone very well. Nordic's sample code is knee deep in copy/paste's and things that need to have 'init' manually called and I just don't do that shit any more. It does have a malloc, which means 'new' works but rather ominously it is possible for the 'growing down' heap to hit the 'growing up' stack with "undefined" results. Hmmm.

The major challenge right now is to get the phone to even realise the nrf even exists. Since other software on the phone *can* see it, this is not going to prove to be impossible although 'time consuming' reserves it's right to bugger things up. As always.

Just a quickie today: while building a C++ framework for BLE I discovered there's one already :) So god bless mbed and their bluetooth team (http://mbed.org/teams/Bluetooth-Low-Energy/).

Mbed itself is weird until you get the idea then it's awesome. It has one of those (dreaded) online IDE things and theirs is really quite crap. It does, however, set up projects their dependencies etc. and can export to all the major embedded development environments. So that's what I've been doing ... and developing in Keil which despite how ancient it looks and behaves does at least have the advantage of working properly.

Oh, and the online build is excellent. Very very impressed by that. I wonder if it's possible to wrap a real IDE (and debugger) around their setup and compile infrastructure. Hmmmmm.

Sorry it's all gone quiet - I've been licking my wounds after not getting through to the next round of the hackaday prize. Rant rant rant.

In the meanwhile, 3 days/week has become 0 days/week so I get a chance to get this going. I've been almost successfully mucking around with the nRF, getting new code to compile and what have you. It's a *moderately* complicated API but if you look at what it does (lots of async) then you couldn't really make it simpler. I think I'll put together a simple C++ framework for building services just so I can clean the code up.

Also: Apache Cordova. Or, rather, PhoneGap that for some reason I seem to have more luck with. It's been going well: I've been playing with a BluetoothLE plugin and, again, kinda complicated due to the amount of async involved. However, it appears that cordova plugins are really quite easy to write so I might just make an 0x05ecure plugin: it would be (I think) easier to develop because I'm more comfortable in Objective C than Javascript; and it would make it easier for third parties to integrate into projects. So, yes, that's it. That's what I'm doing today :)

The counter on the homepage says I have 32 minutes. Everything (for this stage) is done but it doesn't stop me from sitting here shitting myself :)

I've always been bugged about the power for this. For a start, whether or not BLE will 'work' makes the decision between BLE and WiFi. But for now let's assume BLE is a goer. There's lots of talk of a one year battery life and that a CR2032 would be sufficient. An extra bonus from this is that there are a *lot* of CR2032 plus 'one or two buttons' cases being manufactured for the car security market. A better solution might be to use a AAA battery but that then gets really messy around nasty plastic cases screwed onto motherboards and all that yuckiness. I'm currently wondering about using Chinese 'promotional' keychain torches (i.e. http://bit.ly/1pHw4WV) and probably replacing the led end with the radio gear buried in injection moulded plastic. But still screw on/off so we can change the battery.

The other alternative is energy harvesting. Unfortunately this is not a cheap pastime ... TI publish a reference design for a BLE sensor with solar energy harvesting http://www.ti.com/lit/ug/tidu235/tidu235.pdf but it's *huge* and presumably very expensive. I was hoping that a small (25x10mm) solar panel with power management and a small LiPoly would be sufficient but it's beginning to look like (a) it might not be and (b) it'll be a *lot* cheaper to rely on replaceable batteries. I imagine a AAA stores many more joules than a CR2032 while still not being embarrassingly large (although any bigger may well be). 

As per subject a reasonable amount of time was spent getting depressed. I moved it (a virtual hdd file) from my Apple SSD onto a Transcend JetFlash since space is getting a little short ... and soon after it faceplanted. I have no idea if the two are linked.

The good news is I found an *amazing* piece of software for working with Jquery Mobile. http://handhelddesigner.com/ is so, so worth the money. Almost VB like in it's simplicity. Yeah, I had fun with that :) Now for attempting to build http://handhelddesigner.com/ with a bluetooth le plugin then calling it. Hmmm.

Because it's not all fun and games, this week I got kinda stuck doing an explainer video (which, hopefully, is now somewhere up there ^ on this page). I used this software called videoscribe which is the oddest thing ever... It's a genius piece of requirements capture and 'paring back' the options to make a great user experience - which is then totally ruined by (I think) Adobe air. It's slow; saves and loads very unreliably; and all the keys are wrong - undo is not cmd+z, for instance.

So, a sh!tty update but then I didn't get to play around with wires and stuff this week. Mind you, it's only Sunday morning ... wonder if I can sneak some in :)

So, interviewing the nRF51822 - a chip famous for being hackable-as - using the official "evaluation kit". Which means a development kit but not as expensive as the actual development kit.

I "out the boxed" it a few days ago, did what the instructions said and had it doing it's funky thing within minutes. Unfortunately it uses the Keil IDE which at $4k/seat is not really a hobbyist solution but there is "support" for Eclipse. Oh yes. Support. There's lots of moving SDK's to non-default locations, download bits and pieces and gluing them together in Eclipse ... however, it at least appears to work. But, ignore the man behind the curtain! Of the provided examples only one ships with an Eclipse project and it just happens to be the one used in the tutorial. Creating a project? Compiling? Uploading? Up to you, matey. The makefiles appear well written but documentation is more or less zero. I had a shit of a time getting it to compile and go, and the feeling that when something goes wrong I'm going to end up blaming my really-quite-clueless bumbling around inside makefiles as the cause. Damn.

So today I'll try Keil again. You can rent it for $1500/year and if I'm actually putting some serious time into this I'm not a damn hobbyist :) I also reckon Keil is a better investment than yet another 3d printer. More security devices, fewer plastic bunnies.

Just a quick note on hardware trials thus far:

* Broadcom BCM43362 (http://community.broadcom.com/docs/DOC-1422). Despite putting a Cortex-M3 in there, Broadcom really do not want you to hack on this chip. A shame since I'm trying to do it in a single component. That being said it does appear to be more than competent, if a tad expensive and with a slightly bizarre development environment. It can also - and this is really cool - be an AP and an STA simultaneously. I may yet get involved with proxying between two wireless networks :)

* TI CC3200 (http://www.ti.com/product/cc3200) is kinda wonderful. Unlike the Broadcom chip, this one is very much a single chip solution. Out of the box it runs an AP with a web application on it. Everything just works. If it wasn't for a moment of clarity in which I realised Bluetooth LE *would* be good enough, I'd be working with it today.

* Nordic nRF51822 (http://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822) is another *begging* to be hacked single chip solution. Significantly down on processing power from the WiFi chips, as you can imagine, but seems at least likely to be *enough*. I've only just started working on it and while the dreaded Keil is supported there are also guides for using gcc+eclipse. Getting this going is today's work...