Sunday, 26 March 2017

I could get that data quicker by carrier pigeon!

Regular readers of my tweets may have seen a couple of carrier pigeon ones. I don't have any particular interest in carrier pigeons, but it is randomly interesting to see how data transfer can be done in other ways and how it compares with traditional online methods.

Image source: http://cuteoverload.com/2010/04/14/those-carrier-pigeons-just-get-smarter-and-smarter/

I was first inspired to think about this by South African Kevin Rolfe's protest against slow download speeds from his company's ISP in 2009. He flew a carrier pigeon carrying a 4GB memory stick thus beating the equivalent download.

As memory gets cheaper and smaller, it is true to say that the volume of data that can be transmitted over the average home broadband connection is not getting much better, particularly in rural areas. In some places in the UK, it is probably better to get a wireless 4G contract if coverage permits.

Anyway, back to Pigeons. The Internet Engineering Task Force (IETF) have a couple of spoof RFCs which define a standard for IP over Avian Carrier (RFC1149); the revised version adding Quality of Service too (RFC2549).

Physical Payload

Calculating the data payload is relatively easy as you can see:

Payload of a carrier pigeon. This Reddit thread says 75g. Being unscientific as we are, we'll go with that.


  • Weight of normal sized SD: 2 grams 
  • Weight of microSD: 0.4g +/- 0.1g


So basically physically we're talking:


  • 37 full sized SD cards (with 1/2 a full sized one to spare)
  • 187 microSDs (with 1/2 a microSD to spare)


I'm not sure exactly how these would be bundled up, I'll leave that to a Pigeon expert (which I am not).

Data Payload

This is changing on a regular basis as new SDs get released, but here are some examples:


Therefore: 187 microSDs x 2TB = 374TB Data Payload

Calculating Other Internet Speed Related Stats...

So let's try and make some comparison to download speeds. I may not be right with these aspects, so please feel free to correct me in the comments and I will revise the blog. 

We need to work out how fast a pigeon can go. A racing pigeon can fly up to 400 miles at an average of 92.5mph apparently. I don't like to reference the Daily Mail but here we go. As an interesting factoid, the fastest homing pigeon is allegedly the very expensive Bolt, who sold for £300,000 at auction

Using another reliable source (Stack Overflow), let's work out packet time from latency and bandwidth. Using the data payload example above:

Bandwidth = Payload (374TB)
Latency = Total Time (see below)

Throughput over 400 miles (at 92.5mph)
= 4hrs, 19mins, 27.56 seconds
= 14400 + 1140 + 27.56 = 15567.56 seconds

Data / Time
= 374TB / 15567.56

Bytes / Seconds
= 3.74e+14 / 15567.56 = 24,024,317,234 bytes per second
= 24.024 GB per second

Converted to Gbps = 24.024 / 0.125 conversion (according to this site)
= 192.192 Gbps speed (woo spooky homing pigeon IP joke in here somewhere!)

Packet Loss

Whilst we're probably not likely to drop individual data packets, we may drop the whole lot. The risk of catastrophic failure is pretty high when it comes to the pigeon. Carrier pigeons were used in hostile environments quite a lot in both world wars. 32 pigeons have been awarded the "animal VC", the Dickin medal

A hostile pigeon environment. Source: Wikimedia Commons: https://en.wikipedia.org/wiki/War_pigeon#/media/File:Shooting_Homing_Pigeons.png

There are some slightly safer examples. This book claims: “Out of 300 released between 53 and 73 got to Paris”. So if we take the median point of that claim (63), then we have 21% success. That is the optimistic statement. That also means we have a 79% chance of total data loss!

Summary

I didn't consider the time that data might take to load onto a computer - I assumed instant access but obviously that wouldn't be the case.

It isn't likely that the world is going to start using carrier pigeons to transmit all their data, but what it does demonstrate is a viable offline mechanism for data transfer that doesn't involve wires or antennae. The fact that I wrote it entirely on the train whilst connected (in and out, but mostly in) is quite a nice feature of the modern world, for me anyway. However, the internet and web isn't architected for such large latency scenarios and the offline web appears to be neglected by most of the big information companies who seemingly would rather you accessed the data when they can gather data about you. Perhaps it might be useful in the interplanetary/galactic internet/web as a catch-up mechanism - dump a large offline copy onto the next ship going up a space station or planet.

Anyway, I hope you enjoyed the read and would welcome your comments!



Thursday, 24 November 2016

IoT Security Resources

This is a list of useful documentation and links for anyone interested in IoT security, either for building products or as general reference material. The list is alphabetical and doesn't denote any priority. I'll maintain this and update it as new documentation gets published. Please feel free to add links in the comments and I will add them to the list.

Privacy-specific:


Updates:

24th November 2016: Added GSMA self-assessment checklist, Cloud Security Alliance research paper, Symantec paper and AT&T CEO's guide.
5th December 2016: Added GSMA, Nominet and OLSWANG IoT privacy links as well as AIOTI security link.
24th April 2017: Added additional IoTSF links.

Saturday, 22 October 2016

Dead on Arrival? What's next for IoT security?

IoT security is in the news again and it is pretty grim reading. The DynDNS distributed denial of service (DDoS) attack caused many major websites to go offline. Let's be clear - there are many security companies who have suddenly dumped all the insecure webcams and routers that have been out there for years into the new world of the Internet of Things. It is semantic perhaps, but I think somewhat opportunistic because much of the kit is older and generally not your new-to-market IoT products. There is however a big issue with insecure IoT products being sold and if not today, tomorrow will bring further, much worse attacks using compromised IoT devices across the world.



We’re at the stage where we’re connecting more physical things and those things are often quite weak from a security point of view. It appears that it has only just occurred to some people that these devices can be harnessed to perform coordinated attacks on services companies and people rely on (or individuals in the case of Brian Krebs).

I fully agree with Bruce Schneier and others who have said that this is one area where government needs to step in and mandate that security needs to be baked in rather than half-baked. The market isn’t going to sort itself out any time soon, but mitigation, both technical and non-technical can be taken in the interim. This does not mean that I am expecting marks or stickers on products (they don’t work).

There are some quite straightforward measures that can be requested before a device is sold and some standards and recommendations and physical technology is available to create secure products. Some of the vulnerabilities are simply unforgivable in 2016 and the competence of these companies to be able to sell internet connected products at all has to be questioned. Those of us who are in industry often see the same companies time and time again and yet nothing ever really happens to them – they still go on selling products with horribly poor levels of security. The Mirai botnet code released in September targets connected devices such as routers and surveillance cameras because they have default passwords that have not been changed by the user / owner of the device. We all know what they are: admin, admin / admin, password and so on. http://www.routerpasswords.com/ has a good list. With Mirai, the devices are telnetted into on port 23 and hey presto, turned around for attack.

I did notice that there is an outstanding bug in the Mirai code to be resolved however, on github: “Bug: Fails to destroy the Internet #8”

Your company has to have a security mindset if you are creating a connected product. Every engineer in your organisation has to have security in mind. It is often easy to spot the companies that don’t if you know what you are looking for.

Is there another way?

At the grandly titled World Telecommunications Standardization Assembly (WTSA) starting next week in Tunisia, many countries are attempting to go further and introduce an alternative form of information management based around objects at the International Telecommunication Union (ITU) (the so-called Digital Object Architecture (DOA) technology). Some want this to be mandated for IoT. It is worth having a look at what is being proposed because we are told that the Digital Object Architecture is both secure and private. Great, surely this is what we need to help us? Yet, when we dive a bit deeper, that doesn’t seem to be the case at all. I won’t give chapter and verse here, but I’ll point to a couple of indicators:

According to information handle.net, the DOA relies on proprietary software for the handle system which resolves digital object identifiers. Version 8.1 released in 2016 has some information at: https://www.handle.net/download_hnr.html where we discover that:

Version 8 will run on most platforms with Java 6 or higher.

A quick internet search reveals that Java 6 was released in 2006 and reveals plenty of issues. For example "Java 6 users vulnerable to zero day flaw, security experts warn" from 2013. This excerpt from the articles states “While Java 6 users remain vulnerable, the bug has been patched in Java 7. Java 6 has been retired, which means that updates are only available to paying clients.”

Another quick internet search discovers “cordra.org”. Cordra is described “as a core part of CNRI’s Digital Object Architecture”. In the technical manual from January 2016 on that site, we find information on default passwords (login: admin, password: changeit).

"Cordra - a core part of the Digital Object Architecture" - default passwords

If it looks bad, it usually is.

These things are like canaries – once you see them you end up asking more questions about what kinds of architectural security issues and vulnerabilities this software contains. What security evaluation has any of this stuff been through and who are the developers? Who has tested it at all? I’ll come back to the privacy bit at a future date.

The Digital Object Architecture is not secure.

Don’t kid yourself that the DOA is going to be any more resilient than our existing internet – the documentation also shows it is based on the same technologies we rely on for our existing internet: PKI based security, relying on encryption algorithms that have to be deprecated and replaced when it gets broken. I’m not sure how it would hold up against a DDoS attack of any sort. What this object based internet seems to give us though is a license. There are many interesting parts to it, including that it seems that CNRI can now kill the DOA at will just by terminating the license:

“Termination: This License Agreement may be terminated, at CNRI’s sole discretion, upon a material breach of its terms and conditions by Licensee.”

So would I use this for the Internet of Things? No! I’ve touched the tip of the iceberg here. It seems fragile and flaky at best, probably non-functioning at worst. Let’s be honest – the technology has not been tested at scale, it currently has to deal with a small 100s of thousands of resolutions, rather than the billions the internet has to. I can't imagine that it would have been able to handle "1.2 terabits per second of data". Operating at internet scale is a whole different ball game and this is what some people just don't get – incidentally the IETF members pointed this out to CNRI researchers back in the early 2000s on the IETF mailing lists (I will try to dig out the link at some point to add here).

Summary

Yes, we need to get better, but let’s first work together and get on the case with device security. We also need to get better at sinkholing and dropping traffic which can flood networks through various different means, including future measures such as protocol re-design. Some people have said to just block port 23 as an immediate measure (blocking telnet access). There’ll be many future attacks that really do use the Internet of Things but that doesn’t mean we have to tear up our existing internet to provide an even less secure, untested version with the DOA. The grass is not always greener on the other side.

Some more links to recommendations on IoT security can be found below:

Other bodies are also doing work on security but at an earlier stage including the W3C's Web of Things working group


Edit: 30/10/16 - typos and added IETF list


Thursday, 19 May 2016

Improving Anti-Theft Measures for Mobile Devices

I'm pleased to say that the latest version of the GSMA SG.24 Anti-Theft Device Feature Requirements has been published. Many members of the Device Security Group I chair at the GSMA have been personally committed to trying to reduce the problem of mobile theft over many years. This represents just one small part of these continued efforts.

There is no magic solution to the problem of mobile theft as I've discussed many times (some listed below). The pragmatic approach we've taken is to openly discuss this work with all the interested parties including OS vendors such as Apple, Google and Microsoft as well as to reach out to Police and government particularly in the US and the UK where the subject has been of high interest. We've taken their feedback and incorporated it into the work. Everyone has a part to play in reducing theft of mobile devices, not least the owner of the device itself.



Some extra resources:

Some previous blogs on mobile theft:


Friday, 29 April 2016

Introducing the work of the IoT Security Foundation

At Mobile World Congress this year, I agreed to give an interview introducing the IoT Security Foundation to Latin American audiences. If you're interested in IoT security and our work at the Foundation, you should find this video interesting. Enjoy!

IoT Security from Rafael A. Junquera on Vimeo.


Friday, 8 April 2016

Improving IoT Security

I am involved in a few initiatives aimed at improving IoT security. My company wrote the original IoT security strategy for the GSMA and we have been involved ever since, culminating in the publication of a set of IoT Security Guidelines which can be used by device manufacturers through to solution providers and network operators. Here's a short video featuring me and other industry security experts explaining what we're doing.





There's still a long way to go with IoT security and we've still got to change the "do nothing" or "it's not our problem" mindset around big topics like safety when it comes to the cyber physical world. Each step we take along the road is one step closer to better security in IoT and these documents represent a huge leap forward.

Thursday, 24 March 2016

IoT Security and Privacy – Sleep-Walking into a Living Nightmare?

This is my remote presentation to the IoT Edinburgh event from the 24th of March 2016. It was a short talk and if you want to follow the slides, they're also embedded below. The talk doesn't cover much technical detail but is hopefully an interesting introduction to the topic. 



There is a much longer version of the connected home talk that goes into much more depth (and talks about how we solve it). I hope to record and upload that at some point! Slides for this one: