posted by Bryon Moyer
We all know that if we want to be able to… well… transgress someone else’s private computer and internet stuffs, there’s a subterranean culture with a dress code involving black hats where, for the right price, you can get all kinds of tools that will open up all kinds of unsavory possibilities. These are the guys our computer security systems are trying to protect us from. They’re the guys your mother warned you about.
If we keep them out of our computers, then we’re ok. Right?
Oh yeah… there’s this NSA thing going around. Scooping up vast quantities of data (the exact amounts of which seem unclear, but all of which estimates seem to qualify as “vast”). Hmmm… and they’re not getting it from our computers, but rather from folks we pay for computer services (or, in some cases, from folks that offer the services for free). We can protect our data on our systems (or so we believe), but once it leaves us and starts traversing the net, we’ve lost control.
OK, not great, but at least we can encrypt our data and password-protect our files. Someone may intercept the transmission, but at least they won’t be able to read the payload, right? Assuming they’re not consorting with the black hats, anyway…
In order for… I’m not sure what to call the NSA types, since they don’t quite seem like white hats. Gray hats perhaps? In order for the gray hats to break into our actual messages, they’d need to figure out the key or some password or something. And that’s hard to crack – intentionally hard, or else it wouldn’t be secure. So we’re OK. Right?
It’s certainly hard to crack passwords and keys, but, given enough computing power, it’s doable. Of course, software takes time to execute, even when using GPUs; something that’s accelerated in hardware would be just the ticket!
And, voilà! Pico Computing has just announced an FPGA-based acceleration system for cracking passwords. Oops! Wait, sorry – “cracking” is an ugly word. “Recovering” is the preferred euphemism. As in, “Bob left the company and didn’t give us his password. How are we going to open his files?” Why, recover the passwords, of course. One obvious corporate use model. How often is that needed? Hard to say. Probably a lot less often than gray hats might want to recover a password, however.
This is where it’s easy to slip into the Land of Evil. Let’s be clear here: I’m not saying Pico Computing or their technology is being evil. (I know, I know: “Technology isn’t evil, People are evil.”) In fact, Pico Computing isn’t really doing the cracking; they’re accelerating tools from a company called Elcomsoft. Elcomsoft focuses specifically on locked documents that require a password to open, so it’s not so much about decrypting encrypted traffic.
Nonetheless, amidst a sea of technology announcements promising security, I think this is the first announcement I’ve seen that gleefully promises to help compromise security. Although they don’t really say it that way, of course… You can see what they do say in Pico Computing’s release.
posted by Bryon Moyer
We’ve talked before about indoor and pedestrian navigation and the challenges they pose. As part of the ongoing industry effort to crack that nut, Movea recently announced a demonstration of their indoor navigation skills in France and South Korea. I was trying to parse their announcement carefully to catch the nuances of what they were claiming.
First of all, they claim that this is a “first,” but I think the key qualifier is that this is the first time their capability has been proven in a manner optimized for cellphones.
Second, at times it sounds like this was strictly a dead-reckoning solution, at times not. To be clear, this was a dead-reckoning-plus-map-matching (data fusion) solution. Specifically missing was the use of WiFi or other signals to be used as beacons. It was sensors and maps only.
Third, they mentioned collaboration with SCNF in France (the local rail operator) and a subsidiary of SK Telecom in South Korea. The latter in particular made me wonder whether this solution somehow required the participation of third parties (something I’ll address more fully in a piece tomorrow). The answer is that, fundamentally, no, no third-party involvement is required. What they got from these guys was maps of the train stations. This was the data for the data fusion component. At some point, all such facilities will have been mapped (and Google will probably have the maps), but that’s not the case yet.
So, rounding it out then, Movea demonstrated their platform, optimized for cellphones, which combines dead reckoning and map matching, by having people successfully navigate through busy train stations using their solution. Sounds like a pretty good result. You can get more info in their release.
posted by Bryon Moyer
One of the defining characteristics of an embedded system is that you should have no expectations about what it’s made of or how it’s arranged. There are no architecture standards, and that’s how everyone likes it.
Well, ok; not everyone: the poor dudes writing tools for embedded systems have a heck of a challenge dealing with all the variety. And, frankly, some of those tools come full circle and help architects decide how to optimize their systems. But if each variant takes a major project to configure the tools, then that’s not going to work.
Of course, we could try and standardize hardware architectures…
Yeah, good luck getting that one to go anywhere.
Instead, there’s a middle ground being explored by the Multicore Association: it’s called SHIM, which stands for Software-Hardware Interface for Multi-many-core. The idea is to give software tools a way to discover the hardware configuration via an XML file.
This is one of those projects where “restraint” is the name of the game. It would be really easy for something like this to get out of control and far exceed its scope, but the folks driving this – in particular Masaki Gondo of eSOL – are taking great pains to define what this is and isn’t.
For instance, it’s not a complete hardware description of everything in the system. It’s restricted to documenting hardware that matters to software, and it describes the hardware in a manner that makes sense to software (unlike IP-XACT, which is intended for hardware designers). Things like defining the type and number of processor cores, synchronization mechanisms, inter-core communications, memory architecture, interconnect, and virtualization scheme.
They also take pains to ensure that this is not a functional hardware model – you’re not going to plug it into some simulator and have it work. It’s just a description. It’s also not a tool in and of itself; it’s a format for data that can be consumed by tools that others create. So there’s really no threat to anyone in the ecosystem.
It’s partly intended to allow performance estimation of a given architecture, but it won’t be 100% cycle-accurate. It will help with the creation of – but will not auto-create – hardware abstraction layers.
The specific news here is that a working group is starting up to define the details; the first spec should be out sometime next year. You can find more info on the effort and how to participate in their release.