Let's talk about computers on wheels

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-12-05-computers-on-wheels/

Would you agree that the term “computer on wheels” is an accurate way to describe a modern automotive vehicle? When you sit inside a car, do you feel that you are sitting inside a computer? Probably not, but it is not very far fetched to make that claim, and it comes with implications. Read on to find out more and to see if you agree or disagree with this claim.

One point of clarification first, however. While this blog talks about automotive vehicles and more specifically about cars, we can apply this to most other modern automotive vehicle types such as motorcycles, trucks, tractors, ships, boats, airplanes, and so on. Having said that, let’s get started.

Coming a Long Way

The automotive industry has come a long way. While Karl Benz built his first Motorwagen, which we generally consider to be the first modern car, in 1885, the automotive industry has existed since the 1860s. This is not to say that the concept of self-powered vehicles was a 19th-century innovation: the first full-scale, steam-powered tricycle was built in 1796 by Nicolas-Joseph Cugnot, while Ferdinand Verbiest is known to have designed a steam-powered toy vehicle for the Chinese Emperor in 1672. The history goes all the way back to 1478 when Leonardo Da Vinci drew plans for a self-propelled, spring-powered car(t).

In other words, cars in various forms and functions have been part of our lives for many generations. Over the many decades, cars have evolved in ways the first generation designers might not even have imagined to be possible (case in point: NASA’s LRV or the Lunar Roving Vehicle), while their essential functions have mainly remained the same.

Cars have many symbolic values and ideals attached to them as much as there are practical considerations, too. Cars embody the freedom of movement. Cars enable the transportation of passengers and goods, and by extension, create great many business opportunities. Cars offer excitement and memorable experiences in many forms, from social settings to a variety of motorsports. And let’s be honest here, for some people, cars also reinforce their sense of self-importance and public image.

With all that, how many people look at their cars and see a computer?

A Computer on Wheels

A modern car is very much a computer on wheels. More than that, it is not just the engine and a set of wheels (and a heavy right foot) that makes a car move, but a network of dozens of highly specialized computers commonly referred to as Electronic Control Units (ECUs). A modern car might have up to a hundred different Electronic Control Units, such as Central Control Module (CCM), Engine Control Module (ECM), Transmission Control Module (TCM), Central and General Electronic Module (GEM). When you press a button and the side window opens? There’s an Electronic Control Unit operating that too. The number of ECUs in a car grows as manufacturers come up with new features and functionalities for their car models.

Electronic Control Units are connected to other ECUs and a multitude of sensors, switches, electric motors, actuators, and dials via a local network, the Controller Area Network, which is commonly referred to as the CAN bus. Conceptually this is very much like the LAN (Local Area Network) that connects a computer with other computers, local network appliances (printers, TVs, and the like) and the Internet in homes and offices.

So we have established that a car can be described as an automotive computer network, which has the potential to get from zero to 100 km/h pretty darn fast.

For the most part, Electronic Control Units communicate only locally with other units connected to the same CAN bus (there can be other local networks as well, but let’s not go there now). Computers and networks have interfaces to enable communication and interaction, and the same holds true with cars: an ECU is essentially a highly specialized computer that communicates with other similar units over the local Controller Area Network. This network can be physically interfaced with via an On-Board Diagnostics (OBD) port, which is the primary means for mechanics to find out about the state of the car. It is also how the various Electronic Control Units in cars can be programmed.

While OBD can be seen as the primary interface to the car’s network of Electronic Control Units and other related components, there is an increasing number of additional interfaces that enable both physical and wireless communication with the car. For example, a car navigator receives positional data wirelessly from a Global Navigation Satellite System (GNSS) such as GPS, Galileo, GLONASS, or BeiDou. Many cars have a USB-port for people to connect their mobile devices while also offering Bluetooth connections for the same purpose. 4G and 5G connection will become increasingly common as cars are linked up with cloud services to upload car statistics as well as to download apps and updates. Through all this, cars are being transformed from merely providing means of transportation to also contain repositories of personally identifiable data, among other things.

Hackable Interfaces

The thing with computers is that they all can be hacked. From this follows that a modern car can be hacked as well. Sounds a bit dodgy? As it happens, mechanics, motorsports teams and car enthusiasts have been doing this for a long time by programming and tweaking their engine settings and other performance influencing parameters — nothing wrong with that (though it very likely will void the warranty of your car). However, as cars become more sophisticated and easier to interact with, they are also becoming increasingly attractive targets for other kinds of hackers as well — the kind that thinks in terms of attack vectors and exploitable opportunities for various reasons and motivations.

For example, having a “keyless” car is pretty handy, but an RFID-based keys could be cloned. Sharing the car data in an unsecure cloud service could enable outside parties to track the movements of the car or to learn details about its usage. The worst case scenario could be, if the car’s internal network can be accessed from outside, an intruder could be enabled to manipulate some of the car’s subsystems. As potential attack vectors and exploits go, the development of modern cars is opening up opportunities.

This, by itself, does not need to be a problem. Other computers such as Windows, OS/X, and Linux desktops and laptops, smart-phones, and networked home appliances face similar issues. Instead, what can be seen as a problem is the lack of awareness: with ordinary computers, the users are already familiar with concepts such as computer viruses, password safety, data encryption, and having backups. Smart-phone users are learning to be wary of third-party apps, microtransactions, excessive use of network bandwidth, and suspicious calls from international numbers. There are active discussions about information security issues related to the Internet of Things, and so on. However, when it comes to cars, it is probably safe to say that information security concerns are not very high in a list of consumer concerns. The idea of having to install a virus scanner to a car might seem laughable now, but in the not-too-distant future this might actually be a responsible thing to do. While you are at it, you might as well check the firewall of your car and install the latest security patches.

The point is that vehicle information systems continue to become more sophisticated, and various means of interfacing with a car, both physically and remotely, are also increasing. All parties, and especially consumers, need to take the information security issues seriously or, at least, become more aware of the matter. Safety and reliability are very high in the automotive industry’s list of priorities, so there should be no doubt that the same attention will be given to information security concerns as well. It is just that we do not commonly associate with cars topics such as authentication and authorization (beyond having the car keys), network firewalls and encrypted connections, Secure Development Lifecycle (SDL) and other secure programming practices, penetration testing (without using a crowbar), data protection and cloud service issues. At least not yet, in the minds of ordinary people.

Conclusion

In the near future, as driverless cars become more common, people are going to become more aware of the reality that it might no longer be a human who is in charge of a moving vehicle. Vehicle-to-vehicle networks will also evolve and become more common as a means for cars to exchange information about their speed, position, heading, and other actions. This will make it easier to manage the flow of traffic, reduce traffic jams, and improve overall road safety, but not without introducing a new set of information security concerns. For some people it may be challenging to give up their sense of control unless they can substitute it with an improved sense of security and trust.

To conclude, as information systems are becoming ever more sophisticated, the automotive industry is facing new challenges that might not be traditionally associated with vehicle manufacturing. The information security and secure software development practices that are the norm in the software industry will, by necessity, be adopted by the automotive industry to build better and safer vehicles. For example, consider the following twelve practices from SDL:

1. Provide training
2. Define security requirements
3. Define (security and privacy) metrics and compliance reporting
4. Perform threat modeling
5. Establish design requirements
6. Define and use cryptographic standards
7. Manage security risks of using 3rd party components
8. Use approved tools
9. Perform Static Analysis Security Testing (SAST)
10. Perform Dynamic Analysis Security Testing (DAST)
11. Perform penetration testing
12. Establish a standard incident response process

With these and other information security related concerns, you are more than welcome to contact us and have our software and security professionals help your project to be successful.

The Futility of Internet Censorship

Background
Starting today the customers of two Finnish Internet operators, Elisa and Saunalahti are no longer allowed to access The Pirate Bay website. This is because the District Court of Helsinki ruled in favour of the International Federation of the Phonographic Industry, IFPI Finland in October 2011 and ordered Elisa and Saunalahti to block access. However the court ruling did not address the other two major Internet service providers in Finland, TeliaSonera and DNA whose customers are still free to access The Pirate Bay for the time being.

The reason why Elisa was targeted by IFPI was because IFPI's statistics claim that more than a third of Elisa's customers were using The Pirate Bay. Although the court ruling compelled Elisa to block access, it has appealed the decision.

The reaction to this was what you might guess: some Elisa and Saunalahti users will change their ISP to one that does not censor their Internet usage while IFPI website and the website of Finland's Copyright Information and Anti-Piracy Centre apparently faced a denial of service attack and/or were hacked. Meanwhile most people simply won't care, although personally I think they should as this issue relates closely to Freedom of Expression.

YLE has a news article about the case: Pirate Bay block comes into force in Finland.

Personally I think the whole situation is completely and utterly stupid.

Why Internet Censorship Won't Help
The first obvious point is that blocking a static list of domain names and IP-addresses simply can't keep up with content providers. Within a day or so there will be a new domain that is not in the court's list of forbidden domains which will allow Elisa and Saunalahti customers to access The Pirate Bay content again. In the meanwhile, they can still access The Pirate Bay via the Estonian mirror site, thepiratebay.ee which for some reason or other was not blocked among the other Pirate Bay domains.

And then there are the anonymity networks such as The Onion Router (Tor). It takes only a moment to download the ready-to-use browser bundle and voilá, The Pirate Bay is available once more for Elisa and Saunalahti customers as Tor prevents ISPs from seeing what the target website is. Even if the operators would attempt to block access to the public Tor network, users can usually get around this by using Tor bridge relays. Well, I suppose the operator could cut the users completely off the Internet. Not that it would make much difference if the user is determined enough.

So the point is that attempts to force Internet censorship simply won't work in any practical sense. Even the Great Firewall of China leaks well enough and attempts to limit Internet communications during the Arab Spring were not all that successful. While failing all serious attempts to block determined users from accessing forbidden content, it is the common users and legal businesses that end up suffering for it.

So why not try to work with the people instead of against the people?

Appeal to Reason (free tip, no charge)
At least in Western countries there is no intrinsic value in listening to pirated music, watching pirated movies or playing pirated games. It is an effort to gain access and download the pirated content, there are many quality and security related issues and if there are any problems the user can't expect any help from customer support. So why do people do it then? One common reason probably is that they have no other access to the content they want (e.g. a TV series that isn't available in their own country) or the purchase price is simply too steep (60 € for a PC game?!).

Online piracy would become less common if the media producers were a little less greedy, while becoming a little more consumer friendly. Lower the prices a bit while making the content more widely available and more convenient to access it. Sure, the price per unit would be less but if more units are sold instead of being distributed illegally that should end up making a nice extra profit.

For example, I could download pirated copies of my favourite games but I actually prefer to pay for them in the Steam Store and Origin Store because it is much more convenient. Steam allows me to reinstall my games as many times as I want (because limiting the number of installations is just petty and unbelievably greedy); I can install them to as many computers as I want but that's ok because Steam only allows me to play on one computer at a time; my games have access to Steam Cloud that stores save games and settings while also accessing the Steam community so I can keep in touch and play with my friends easily. On top of that there are good discount offers, and I can donate extra copies to my friends for free. It is safe, easy and most of all, convenient and that is why I willingly buy my games from Steam instead of wasting my life with pirate copies.

Another good example comes from Manning Publications. I often buy books through their Manning Early Access Program, which allows me to buy a book for a discount fee while it is still being written. This enables the community to cooperate with the author, which in turn results in higher quality when the book is eventually finished. During the MEAP peried Manning sends me PDF work-in-progress copies of the book and when the book is completed I get the final version as a PDF. If I paid little extra I will also get the print copy in mail. When the eBook formats become available (.epub and .mobi) Manning sends me a friendly email with instructions how to download them for no extra charge.

So there are good examples how to provide good customer service with an open attitude, and still do good business. There are many ways to make media access more convenient for the consumers and here's the age old truth: people will give their money away and feel good about it if they can also feel that they are getting their money's worth in exchange.

So IFPI and the like around the world, instead of thinking that it is your God given right to strip people of their money whenever half an opportunity presents itself, why not think about how to give better value for money? A happy customer is a steady customer. Why not try to find ways to provide better services to the consumers, so that instead of running after free pirated copies they would choose convenience over effort for a modest fee? Let's just be sensible about it, alright?

And if you don't know how, just contact me, and for a reasonable fee I can solve your problems and make you feel good about the result ;-)

Better protection against GPU brute force attack with bcrypt (and common sense)

Summary
For those of you who prefer to get to the point right-away instead of being lead to it, I have two points to make.

First, when it comes to password security it is better for common users to use longer (>8 characters long) and less cryptic passwords than shorter yet morecryptic passwords. By cryptic I mean passwords including lower and upper case characters combined with numbers and special charaters such as '#fK1~2'.

Why? Because a common users are more likely to be made vulnerable when their favourite site gets hacked during which the user database is stolen along with the usernames, passwords and the rest. At that point there will not be a single person trying to guess your password but instead a tireless GPU driven software doing a brute force attack by systematically going through all possible character combinations at speeds exceeding many hundreds of millions combinations per second: your sneaky 6-character cryptic password would be cracked within few seconds.

That is not to say the passwords should not have any special characters and numbers and the rest: there should as those make dictionary based attacks less likely to succeed. The point is that while having more characters in a password makes it stronger but overly cryptic words are harder to remember so if you have to choose between length and cryptic it is better make the password a little less cryptic and that much longer. The XKCD says it oh, so well, as usual :)


The second point is for software architects and developers who can significantly improve the security of their hashed passwords by adopting the BCRYPT hash function instead of common SHA-2 variants (and surely none of you are still using MD5 or SHA1 hash functions to encode passwords these days, right? Right?)

Why? Because bcrypt can be made very expensive to use so that it would take milliseconds (or even seconds, if you have paranoid tendencies) to encode a password instead of microseconds which is achieved by most of the common hash functions. It is trivial to spend about 0,6 seconds to encode user's password during registration and login as these operations happen reasonably rarely. However, those 600 milliseconds per single encoding becomes anything but trivial when a hacker attempts to brute force through all the passwords in your user database. As last line defences go, bcrypt should be preferred over other hash functions including SHA-2 variants.

Want to know more? Keep on reading.

The Problem
It has long been a common practice to store user passwords in a hashed form instead of the clear, human readable form. For years hash-algorithms such as MD5 and SHA-1 have been the preferred methods, but these days neither should be used for any security related purpose as they have well-known vulnerabilities. Instead many recommend that these days SHA-2 should be used, as it has no known exploitable vulnerabilities (apart from inept and lazy people who are using passwords that are too short and simple to stand against educated guess).

For those with a less technical background, a hash function is a one-way cryptographic algorithm that takes a variable length input and calculates a value that is unique for the specific set of data (e.g. file or string). It is not possible to reverse given hash value to reveal what the original value was. So when applied to passwords the way to verify if the given password matches with the hashed password in the database, the given password is hashed with the same algorithm and if the two hash values are identical it means that the right password was given and use may login.

For example, if the password is 'secret' the hash value (SHA-256) is
'2bb80d537b1da3e38bd30361aa855686bde0eacd7162fef6a25fe97bf527a25b'

Why passwords should be stored in their hashed form? Obviously hashing does not protect against somebody  trying to log in to service by using another user's username while attempting to guess what the password might be (to protect against this the service should temporarily lock user's account after n failed login attempts). Instead hashing the passwords is the service's last line of defence when a hacker gains unauthorised access to the user database.

User databases get hacked all too often. For example, in 2011 Sega lost 1.3 million user passwords, Sony's Playstation Network got hacked at least twice after which about a million usernames and passwords were made public by the hackers, not to mention many other known cases over the past few years (and not nearly all cases are known to public).

Hackers have been quite busy indeed but the designers and developers of those services should also take a good look at the closest mirror: after all, hackers merely exploit the existing holes in various libraries and services, many of which have been publicly documented.

Cause of Problem
While hashing is a good way to protect a password against the eyes of unauthorised mortals, they can be vulnerable against brute force attacks. Modern computer components are simply so fast and efficient that brute force attacks (where each and every possible combination is tried until the right combination of characters is found) have become quite reasonable option for attackers.

A modern brute force attack utilises GPU instead of more traditional CPU. Consider this: while a CPU based password recovery tool might take about a year to crack an eight-character password, a similar GPU based password recovery tool could do the same trick in less than a day. In another words, a 13-year old with a gamer's desktop computer and simple software tool could crack a list of typical hashed passwords within hours or days, if not in minutes. Now consider for a moment about what a well-resourced and determined professionals would do to passwords in the user database of your favourite web site should they gain access to it.

For example, a dirt cheap ATI Radeon HD 5450 can handle about 52 million SHA1 or 126 million MD5 hash computations per second. Upgrade to ATI Radeon HD 5970 and you would be doing about 2 320 million SHA1 or 5 631 million MD5 calculations per second, and that is with just a single GPU. Most desktops can have two linked GPUs, including the one I have under my desk that I have dedicated just for gaming and LAN-parties.

To put things into perspective, ATI Radeon 5770 can crack a five-character password under one second while a typical CPU might be do the same in about 24 seconds or so. A six character password would take about four seconds for 5770 to crack, and a seven character password would be sorted in about 17 minutes. The respective times for a typical CPU would be around 90 minutes and four days, or so.

The Solution?
Obviously there are no guarantees but there are ways to frustrate most attackers to a point when the reward just isn't worth the trouble.

For a common user the best protection is not to use overly cryptic and hard to remember passwords with caps, numbers and special characters (e.g. #fK1~2) but simply to use longer passwords. For example, if the system is using ASCII that has 95 printable characters, each new character in the password multiplies the number of possible combinations by 95. On the other hand, if your password is just a common word then you are wide open for dictionary based attacks and guesses of people who know you. Go for the middle ground.

At the same time software architects and developers should ditch the ye olde SHA-2 variants and similar algorithms and move to BCRYPT.

Bcrypt is a Blowfish variant that has one very important aspect that sets it apart from most other hash algorithms: it can be made very expensive to use in a world where cheap equals bad. Most hash algorithms have been optimised to calculate a hash value for large sets of data as fast as possible (for example, an AMD64 CPU can calculate MD5 hash for 335 MB of data in one second) which is great when one needs to find out if two large data sets are identical, but bad when dealing with common <10 character passwords, as shown earlier.

Bcrypt on the other hand is designed to be slower instead of faster when calculating the hash thus making it easy to increase the expense of brute force attack as a single hash calculation would take milliseconds (or even seconds) instead of microseconds. Combined with properly long unobvious passwords bcrypt can seriously frustrate GPU based brute force attacks while attackers relying on CPU should not even bother.

It is important to put this into proper context: it is perfectly fine for a password hashing to take about a second during registration and login as these happen fairly rarely: a typical user registers only once and might login to service few times a day whereas a hacker would need to go through as many individual passwords in as short time as possible. Given certain amount of time the hacker will have some of the bcrypt encoded passwords cracked, but not nearly as many as he would have if the passwords had been e.g. SHA-256 encoded, whch i in turn would be less than when dealing with *gasp* MD5 encoded passwords.

Another very nice thing about bcrypt is that it can be adapted to match Moore's Law: it has a work factor that can be freely increased as computers become faster as well as to tweak the balance between performance and security. Bcrypt is available for most programming languages and for example the Grails Spring Security Core -plugin by Burt Beckwith makes the using of bcrypt practially trivial.


Hopefully in the future I will not be seeing web sites that limit user passwords to max 8 characters while enforcing ridiculous character inclusions while at the same time I do hope to see frustrated hackers pissing their lives away by trying to brute force through bcrypt encoded passwords. It would be a nice start, but only a start as far as improving software security is concerned.