Amazon proposes the following data flow for IOT. It is built with AWS and the recently acquired 2lemetry and its ThingFabric platform.
https://aws.amazon.com/iot/how-it-works/
https://www.linkedin.com/pulse/iot-aws-reinvent-quick-hits-matt-trevathan
Components: Rules Engine, Registry, Shadows (state tracking), Data based decisions, Integrations with AWS (Redshift, Lambda, S3, Kinesis, DynamoDB)
This conference has a focus on integration between technologies and is held with API World. A dominant theme was connected cars.
ActiveScaler demonstrated its Connected Car platform and API that delivers five types of information. It had a great session with visits from a number of car companies, partners, vendors advisors, investors and interested public.
The highlight was a visit by Maria Roat, CTO, US Department of Transportation where she and her colleague shared their views on the evolution of transportation technologies with ActiveScaler team.
ActiveScaler demonstrated an app that connects the car to the cloud to provide rich vehicle and driver analytics in real time.
At the Salesforce conference were several interesting IOT demonstrations.
One of them could Docker to be run inside a Raspberry Pi. This can be used for seamless OTA upgrade of IOT software. Another allowed instant analysis of the chemical composition of a drug and the information is connected to an app.
Another interesting demo was Built.io, which is like an IFTTT for different apis and IOT flows – a virtual circuit diagram allows inputs to be cascaded together in a flexible manner to achieve a variety of outcomes.
Salesforce made the announcement of the IOT Cloud which is built on Salesforce Thunder, a massively scalable real-time event-processing engine. Business can create alerts or filters to identity important data from event streams. This can be used to send alerts from manufacturers to customers or customers to manufacturers, for instance for a malfunctioning device or for a car recall.
Marc Benioff – “The Salesforce IOT Cloud will empower businesses to build proactive 1:1 relationships with their customers to deliver a new kind of customer success”.
Here’s a review of this announcement with the opinion that it is currently more of a positioning statement than a real capability – http://www.zdnet.com/article/dreamforce-2015-salesforce-thunder-unavailable-2016/
A CAN is a Controller Area Network. Electronic Control Units (ECUs) are networked together in a car using a bus based on the CAN standard. A car will have one more CAN buses which are typically accessible via the Onboard Diagnostics (OBD II) port.
The CAN allows a distributed network of micro-controllers and devices to do real time messaging with each other with CAN packets, to exercise real time control. It is used in industrial control systems, vechicles such as airplanes and ships, and automotive systems.
ECU examples are Airbag, HVAC, ABS and Engine Control Unit.
Some CAN related security resources –
A podcast interview with Chris Valasek: https://securityledger.com/2015/07/podcast-interview-with-car-hacker-chris-valasek-of-ioactive/
Most cars do allow CAN access via OBD. Tesla does not, but the CAN information is still accessible via another port.
It may sound unusual that the OBD port meant for diagnostics should allow sending commands to the CAN bus, but this is in fact possible, in part because there is no source identifier or authentication build into CAN packets.
What if an ECU itself has some kind of problem or degradation ? This can increase vulnerability when combined with open CAN bus access.
For example, there were two independent recalls in early 2015 related to defective airbag deployments. The Jeep recall was due to software that detected rollover aggressively and deployed the airbags. The NHTSA recall was due to Takata airbags with faulty inflators.
As we bravely head to an IOT world where various devices and controllers are networked to external entities, such concerns will increase.
There are attacks on other car interfaces such as bluetooth, telematics unit and remote key. Recently (July) there was an attack on Jeep which caused an update to fix the bug. The Israeli media reported a couple startups, Argus and TowerSec could have prevented this attack. Update Jan 2016: TowerSec is acquired by Harman – CES 2016 announcement.
Cisco recently acquired OpenDNS and its security offerings.
The Domain Name Service is a hierarchical lookup service that converts human readable names to IP addresses that are used for routing. As such the DNS lookup servers can see the names being accessed, their access trends, web security attack patterns such as phishing redirects and so on.
But how did OpenDNS come to focus on security ? It was preceded by a free DNS service called EveryDNS started by David Ulevitch in his college dorm in 2001. The free nature of it attracted an interesting clientele– a number of malicious services, sites and agents. This gave EveryDNS visibility into this part of the internet – both the customer view and a real-time view. David realized the potential and started a new company OpenDNS with both a free+paid dns offering and a growing number of security services.
In 2012 OpenDNS offered an Umbrella service to blacklist malicious sites. The most interesting offering is its OpenDNS Security Graph. The Umbrella Security Graph maintains and automatically updates malware, botnet, phishing domain and IP blacklists. This is then sold to enterprises – a higher margin business than providing DNS lookup alone.
Verisign is also in the DNS security business after it sold its certificate business to Symantec.
Tesla is an advanced computer on wheels. How is security for such systems designed ? Snippets from below are insightful.
http://www.wired.com/2015/08/researchers-hacked-model-s-teslas-already/
“Two researchers have found that they could plug their laptop into a network cable behind a Model S’ driver’s-side dashboard, start the car with a software command, and drive it. They could also plant a remote-access Trojan on the Model S’ network while they had physical access, then later remotely cut its engine while someone else was driving.”
“Tesla distributed a patch to every Model S on the road on Wednesday. Unlike Fiat Chrysler, which recently had to issue a recall for 1.4 million cars and mail updates to users on a USB stick to fix vulnerabilities found in its cars, Tesla has the ability to quickly and remotely deliver software updates to its vehicles. Car owners only have to click “yes” when they see a prompt asking if they want to install the upgrade.”
“The Model S has a 17-inch touchscreen that has two critical computer systems. One is an Ubuntu server responsible for driving the screen and running the browser; the other is a gateway system that talks to the car. The Tesla gateway and car interact through a vehicle API so that when a driver uses the touchscreen to change the car’s suspension, lock the doors, or engage its parking brake, the touchscreen communicates with the gateway through an API, and the gateway communicates with the car. The touchscreen never communicates directly with the car. “At least so our research has found so far,” Mahaffey says.”
“The Model S has an Ethernet cable for diagnostic purposes and by connecting to this they were able to get access to the car’s LAN. This allowed them to uncover information about the firmware update process, such as the configuration of the VPN the car used to obtain updates as well as the URLs from where the updates were downloaded. They also found four SD cards inside the car that contained keys for the VPN structure, and they found unsecured passwords in an update file that allowed them to gain access to the Tesla firmware update server. “By using the VPN credentials we got from the SD card, we were able to configure and open VPN clients to go and talk to Tesla’s infrastructure and mimic the car.”
Even though Tesla provided the update quickly, having unsecured passwords in a file that allowed access to go to the firmware update server should alert one to the risks of connected cars.
From http://thehackernews.com/2015/08/hacking-internet-of-things-drone.html
Security researchers have developed a Flying Drone with a custom-made tracking tool capable of sniffing out data from the devices connected to the Internet – better known as the Internet-of-things.
The Target data breach in 2013 affected 40million credit cards. It was traced back to an onsite HVAC (that was remotely accessible for billing) being on the same network as the rest of the system . The credentials for the HVAC were breached and used to attack the internal computers.
The link below discusses a comprehensive security plan for a building automation system. The connected components are identified and the network and systems are designed for authorized access.
http://www.automatedbuildings.com/news/may14/articles/llnl/140425010101llnl.html
One can see such a plan being useful for a number of sensor/IOT systems – e.g. energy, temperature and and video sensors.
Web authentication and SSO typically imply that state is maintained on the server to indicate whether the user is logged in or not. The identity provider maintains this state and the identity consumers check this state with the identity provider. The protocol and message format differ in different implementations – SAML, OAuth, OpenID and several others.
SAML is the richest, most flexible auth protocol, but also most complex to implement. It covers the most number of use cases. The security assertions about an identity are captured in an xml format which can be exchanged between providers and consumers over the web.
OAuth is simpler and requires fewer things from the implementer. OAuth 2 has become a vehicle for enterprise use cases like SAML. SDKs for OAuth are available.
OAuth 2 and OpenID both use Json WebToken (JWT) which is a JSON format specification for interoperability.
OpenID Connect is the most open and newest of the three. It reduces reliance on checking auth state with the identity provider by embedding more information in the JWT and standardizing things like scope to increase interoperability. If officially supports authentication use cases, unlike OAuth2 which is designed for authorization, but is used for pseudo-authentication.
A key consideration when deciding on an implementation is the scalability requirement. Ideally the system is structured to keep the least amount of state (zero) on the server. This is not true of most SSO implementations.
Like a stateless NFS server, based on leases for lock state that can be refreshed, a stateless implementation for SSO is possible (classic NFS has no open, only lookup). The tradeoff is that revocation is not as easy and reporting may need to be handled differently than with a stateful implementation. Here’s a discussion – http://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration
Update. Here’s another discussion which points to some tradeoffs – https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens , basically that this is more useful for SSO and API implementations not simple websites.
Here is a talk from Synack on OS X malware. iOS is locked down but OS X is much more open – obviously one can download applications outside the appstore and load and run apps and dylibs that are unsigned. This impacts security for a connected home with many devices with hubs that may be OSX based.
For example here’s a description of remote control of a baby monitor – http://www.zdnet.com/article/iot-security-under-scrutiny-as-apple-looks-at-smart-home-system/ .
In a pure transposition cipher, the text “AAAAAA” is transformed to “AAAAAA”.
In a pure, static substitution cipher, the text “AAAAAA” is transformed to (say) “ZZZZZZ”.
In a vignere pad, the string “AAAAAA” input is transformed to an output which is equal to the keyword (or an offset of all its letters, making it easy to guess).
If the keyword were completely random and not used again, but still shared between two parties, one would arrive at the one-time pad, which has perfect secrecy. Is this possible ? Wikipedia says information-theoretic secrecy is used in top secret communications.
The Enigma cipher was a dynamic substitution cipher where the substitution maps changes as the rotors rotate before each letter is entered. This machine and its code-breaking machine is the subject of the movie The Imitation Game, discussed in my previous blog post.
The number of permutations of the 26 alphabet, 26! is ~0.4 billion billion billion – 0.4 octillion – 4 followed by 26 zeros. This is the number of maps from the set of 26 letters to itself, and the size of the space of all maps that the German Enigma machine played in.
The number of maps the Enigma actually utilized to transform an input letter to another is much smaller. At the core the machine has a handful of rings which implement fixed maps. Each individual ring implements one fixed permutation map of the numbers 1-26 to itself. The fixedness is important – bit hard to believe as it appears to considerably simplify the attack – the ring does not vary its map (input-output permutation) except due to rotation of the ring – which can be in any of 26 different positions. With 3 rings, they could be ordered in 6 ways and total of 6×26^3 maps – only about 106,000. With the 3 rings chosen from 5 available rings instead of 3, there could be 5x4x3 or 60 combinations and 60×26^3 maps – a million. At each letter entry the rotors would change to use another of the ~10600 maps. Guessing a valid map (10^5) from the much larger space of all maps (4*10^26) made cracking the code near impossible – assuming good operating procedures. The plugboard implemented another (fixed) permutation.
The Polish bomba utilized leaked knowledge of both the maps and the known number of rings – and with that information tried a brute force attack for the 3-ring design. Even with knowledge of the machine internals this required ingenuity to look for patterns in the messages – duplicate input letters that were frequently mapped to duplicates in the output reduced the search space.
This worked until the Germans added two more rings to the original 3. At this point the Polish method was not effective. Turing understood a different method was needed.
The machine that was built at Bletchley park and was shown in the movie was also a brute force machine, not a general purpose computer (as I assumed before the movie). It used input text that was likely to be in the transmitted data, encrypted it in several combinations then compared it with the actual transmissions. This is called a chosen plaintext attack.
An interesting aspect in the movie was how hard Turing had to fight to keep the idea of this machine alive as it was an unknown and unproven concept to the military generals. When he succeeded and U-boats were started to be destroyed (with a cover of air surveillance as the source of sighting the subs), Admiral Karl Dönitz on the German side had to convince his own chain of command of the need to change Enigma – a request deflected for several months as the German chain of command bought the air surveillance story. Dönitz eventually succeeded in adding a fourth rotor and the submarine attacks subsided immediately – until a couple subs were captured and the details of the newer rings were found by the British.
In a way, the machines on either side were trying to get smarter but were slowed down by a human bottleneck. The selfish machines.
The basic idea of a small set of pseudo-random (fixed) permutations embedded in a larger space of permutations is utilized in block-ciphers (DES, AES) in form of P-boxes. A difference is the presence of S-boxes which achieve mixing of the inputs so an input pattern does not have a deterministic effect on output patterns.
What’s interesting is an information theoretic notion of security which is not susceptible to attacks. Some of these ideas are used in the IDEA cipher.
Secure Machinery 