Wibu-Systems Blog

Endpoint Security for a Rail System: Another Industrial Internet System Success Story

Posted by Terry Gaul on Nov 18, 2015 10:45:11 AM

CodeMeterTrain_550.jpg

When At&T, Cisco, GE, IBM and Intel founded the Industrial Internet Consortium in March 2014, I wonder if they had envisioned how quickly the International technology community would embrace the their mission to catalyze and coordinate the priorities and enabling technologies of the Industrial Internet. Many amazing collaborative solutions have already emerged – for example, RTI and Siemens teamed up on a solution to network and control hundreds of wind turbines for better control and optimization, and National Instruments and Airbus have developed tools for smarter factories. Just take a look at the many case studies published by IIC members in a variety of fields – communications, energy, healthcare, manufacturing, transportation and logistics, and security – and you will gain a sense of the enormous potential for the connected world.

Industry collaborations and technology partnerships are the foundation upon which these innovative Industrial Internet systems will be created. Wibu-Systems’ main focus is to provide the protection platform for our partners to secure these next generation systems. For example, as a member of the Infineon Security Partner Network (ISPN), we have worked closely with Infineon and other leading security vendors to secure devices and systems in various applications. In a recent collaboration, we employed Infineon’s SLE 97 security controller and our CodeMeter Embedded Protection to deliver an endpoint security solution to safeguard railway control systems.

Wibu_CS_Endpoint_Security-c.jpg

In this use case, the safety of the application was paramount. Hardware components had to comply with an extended operating temperature range, moisture challenges, and vibrational conditions. The software security elements were tasked to guarantee the highest level of security against cyber threats while protecting IP against reverse engineering and piracy. And, the solution needed to be compatible with the real-time VxWorks operating system already in use. The multiplicity of potential attack vectors called for an endpoint security solution. The CodeMeter-based solution met all these criteria and was then integrated into the existing power-controlling infrastructure.

You can read more specific details about the cryptographic elements of the solution, secure boot mechanism and other innovative development and implementation details in this case study.

 

Topics: CodeMeter, Code Integrity, embedded security, Internet of Things, cybersecurity

From Stuxnet to iPhone: The evolution of modern computer viruses

Posted by Rüdiger Kügler on Sep 22, 2015 12:50:13 PM

Whether it be Stuxnet or an iPhone virus, it is people who are the cause for trouble. But let’s go back to how the story began: Just a few days ago, it was unthinkable for an iPhone to be infected with a virus. The concept of the App Store itself – which only allows the distribution of software authorized by Apple – seems to suggest that the spread of viruses through their apps would be impossible. It is the same belief we had for one of Siemens’ controllers years ago: "They can never be subject to viruses." It was just a matter of time before both assumptions were proven wrong.

What happened then? Any software running in a closed system, like an iPhone, must be signed by a software publisher. For this purpose, the developer uses a key pair consisting of a private and a public key. The private key is kept secret and used for the cryptographic signature. The public key is signed by the manufacturer of the closed system, in this case Apple, with his private key (root key). The resulting electronic document – which includes the developer’s public key and the signature from Apple – is called a certificate. For validation purposes, the closed system only requires the public key (public root key) that is already included in iOS by Apple: "Only developers that I know and trust, are allowed to run software in my closed system."

In a jailbreak, this mechanism is undermined by the user of the device. A modified operating system skips this check. While any software can then run on the device, the user of a jailbroken phone inadvertently opens the door to virus threats as well. However, the issue now affects respectable users (those not using jailbreaks) too.

And why is the iPhone case so similar to Stuxnet? In both cases, the development environment of the software developer was attacked. This means that the virus had already taken hold of the software after compiling, but before signing the application. When the developer signed the software, he included the virus as well, which thus passed any verification controls unnoticed. Compared to this, the attack via Stuxnet occurred at an alarming lower level. The new incident exploited human vulnerability – convenience first and foremost – by offering a tampered pirated copy of XCODE for download. China was affected more significantly by it, as the use of pirated products is widespread and usually regarded as a minor offense.

What are the takeaways from this incident?

  • Even free software needs protection against piracy, protection against reverse engineering, and very robust integrity protection.
  • The signature of a software must be made in a trusted environment. For instance, the key should be safely stored in a secure hardware element.
  • Even in a closed system, we should not assume that all software will be reviewed in detail and take our security for granted. The review process is only one link in the protection chain.
  • A security solution is only as good as the weakest point in the chain. Even the best approach may be undermined, if it is not done holistically.
  • A protection solution must offer the same level of security across all platforms. This is where a professional solution like CodeMeter comes into play.

Siemens responded quickly and did a good job after all. Let's hope that Apple is equally responsive. If you are ready to implement the lessons learned from this episode, you can count on CodeMeter, our all-in-one protection suite, and on the professional expertise of our team.

Topics: software protection, CodeMeter, Code Integrity

Integrity Protection for Embedded Systems

Posted by Terry Gaul on Jun 9, 2015 11:00:00 PM

connectedplanet-257pxSoftware for embedded systems is based more and more on open system platforms – Linux Embedded, VxWorks, Windows Embedded, QNX and many others. In addition to powerful core functionality, one of the main reasons to use open platforms is their implementation of standardized interfaces for loading code or calling system functions (APIs). Such standards simplify software development between several teams within a large enterprise or even between different software companies. And similar to the success of software for traditional desktop systems or smart phones, developers can find more solutions that can be purchased from third parties instead of developed in-house.

However, this new open world also makes embedded systems vulnerable to attacks from two main challenge points. First, the embedded system can be attacked directly from the Internet. Execution codes can be replaced or modified by malicious code during code updates. Weaknesses in the code itself can also be exploited. Secondly, hackers have access to the same open source information as the developer. With knowledge of the execution code binary structure, hackers can use powerful development/analytical tools to directly modify the code in a static attack. Furthermore, with knowledge of the memory and process architecture, the hacker can initiate a dynamic attack by inserting malicious code into the boot process.

Recent examples of such exploitations include successful attacks to POS systems to steal credit card numbers or ATM machines to steal cash. The Internet of Things (IoT) now brings embedded systems with such open platforms into a globally connected environment that is highly vulnerable to all types of attacks from hard-to-identify hackers who can be located anywhere in the world.

One solution to prevent such attacks is the installation of security barriers between the code and the open internet, such as firewalls or strict access control to the critical code. But the structure of such barriers in larger installations of embedded systems – an automobile assembly plant for example – is quickly becoming very complex with a high risk of security leaks. And if a hacker can find one such leak, he or she is now “inside”, and knows the details of the platform in use, and can modify the existing code or even upload and start new code to perform malicious attacks beyond simply analyzing, copying or deleting data.

A more effective solution is to protect the running program code itself against any modifications and also prevent the loader of the operating system to start any unauthorized code. This also includes protecting the open system platform itself to prevent hackers from installing their own loader. And finally the BIOS of the embedded system should prevent any loading of an unauthorized operating system.

There are two advantages to this approach. First, the execution code is authenticated by a private key accessible by the developer or owner of the key; no other source is possible and the code cannot be modified during delivery or on the embedded system. Second, the execution code is encrypted and cannot be easily reverse engineered by a hacker or a competitor.

Our CodeMeter technology provides this type of code protection at all levels of an embedded system where software components are running. The authentication process begins in the BIOS, which will only start an authorized operating system, through the loader in this operating system which only accepts execution files of authorized programs, and up to the ability that these programs can load only applets or dynamic libraries with authorized dynamic extensions. This code integrity protection is based on sealed code, which cannot be modified at the file level, and which is verified by a private/public key schema. All components (BIOS, operating system, optional loader, application and applets) can come from different development departments or companies. Dynamic updates of any component are possible as long as the updated code is authorized as well. It is also possible to remotely update, extend or remove the required keys in a secure manner.

I invite you to view a pre-recorded Webinar to see how CodeMeter enables the flexibility of secure code upgrades, which will be required in the ever evolving world of connected embedded systems, with the security of the closed, non-changeable, unconnected systems of today.

Access the recording now.

Topics: CodeMeter, Code Integrity, embedded security

Secure Software Updates via Embedded Integrity Protection

Posted by Marcellus Buchheit on Dec 17, 2014 7:00:00 AM

Software for embedded systems is based more and more on open system platforms, such as Linux Embedded, VxWorks, Windows Embedded, QNX and many others. In addition to powerful core functionality, one of the main reasons to use open platforms is their implementation of standardized interfaces for loading code or calling system functions (API). Such standards simplify software development between several teams within a large enterprise or even in different software companies. And similar to the success of software for traditional desktop systems or smart phones, you can find more solutions that can be purchased from third parties instead of developed in-house.

However, this new open world also makes embedded systems vulnerable to attacks from hackers who also know the system platforms very well. Current examples of such threats include successful attacks to POS systems to steal credit card numbers or ATM machines to steal cash. The IoT now brings embedded systems with such open platforms into a globally connected environment that is highly vulnerable to all types of attacks from hard-to-identify hackers located around the world.

One solution to prevent such attacks is the installation of security barriers between the code and the open Internet, such as firewalls or strict access control to the critical code. But the structure of such barriers in larger installations of embedded systems – an automobile assembly plant for example – is quickly becoming very complex with a high risk of security leaks. And if a hacker can find one such leak, he or she is now “inside”, and knows the details of the platform in use, and can modify the existing code or even upload and start new code to perform malicious attacks beyond simply analyzing, copying or deleting data.

A more effective solution is to protect the running program code itself against any modifications and also prevent the loader of the operating system to start any unauthorized code. This also includes protecting the open system platform itself to prevent a hacker from installing his own loader. And finally the BIOS of the embedded system should prevent any loading of an unauthorized platform.

Wibu-Systems CodeMeter technology provides consistent code protection at all levels of an embedded system where software components are running. Beginning in the BIOS, which will only start an authorized operating system, through the loader in this operating system which only accepts execution files of authorized programs, and up to the ability that these programs can load only applets or dynamic libraries with authorized dynamic extensions. This code integrity protection is based on sealed code, which cannot be modified at the file level, and which is verified by a private/public key schema. All components (BIOS, operating system, optional loader, application and applets) can come from different sources. Dynamic updates of any component is possible as long as the updated code is authorized as well. It is also possible to remotely update, extend or remove the required keys in a secure manner.

This technology enables the flexibility of secure code upgrades, which will be required in the ever evolving IoT world, with the security of the closed, non-changeable, unconnected systems of today. It is currently available in the latest version of VxWorks Real Time Operating System and will also be available for other platforms in the coming months. The technology is based on secure keys which are stored in a security device and which can be integrated as a chip directly into the system hardware or attached as a USB Stick, SD, microSD or CF Card.

Integrity Protection White Paper

If you are interested in learning more about Integrity Protection for embedded systems, download our whitepaper.

Topics: CodeMeter, Code Integrity, embedded security

Secure Software Licensing

Posted by John Browne on Jul 31, 2012 9:39:00 AM

We talk a lot about copy protection in this space but what I want to focus on today is what is meant by the phrase "secure software licensing." Let's unpack the term and look at each component separately:

Secure

The sina qua non of all this is security. If your software isn't secure nothing else that follows matters. By "secure" we're talking about preventing a host of bad things you don't want to happen:

  • License piracy: your customers bought a certain right or entitlement to use your software. That entitlement needs to be secured in such a way that the customers can't accidentally or even deliberately use more copies than they have purchased. Addditionally, you need to be able to ensure that non-customers cannot use your software until they have a license (i.e., become a customer).
Locked briefcase
  • Code cracking: Modifying the executable code to circumvent or disable any license verification is pretty common these days, particularly for very popular applications. You can find these cracked versions on the usual Internet sites. But increasingly even niche-market B2B software is being cracked, particularly for use in the developing world. 
  • Reverse Engineering: Reverse engineering of the original IBM PC BIOS led to a slate of instant clones competing with IBM for the same market space. Reverse engineering of software is not illegal in the USA, since it's considered fair use under the copyright laws. Protecting your software against this is critical.
  • IP Theft: You're in the software business, and in software your most important assets are your IP--some of which probably exists as algorithms in your code base. Do you want your competitors to see how you solve tough problems and use that to their advantage? Of course not. 
  • Code Tampering: How do you know that the binary you have is the binary that was created originally? How can your users know? In some applications, this may be the most important question of all. For example, if you're selling applications to the military or healthcare industry, being able to assure them the there are robust internal safeguards against the code having been modified before they execute it can be vital.
  • Malicious attacks: similar to code tampering, but in this case you want to ensure that no malware payload has been inserted at any time. Further, you want to know that the code can't be modified on the user's machine. 
These are some of the more common areas for concern in secure software licensing. In the next blog post, I discuss the next part of this expression: "software."

Topics: Code Integrity, CodeMeter, License Management, Copy Protection, Anti-piracy

Are your embedded systems secure?

Posted by John Browne on Jun 11, 2012 3:20:00 AM

This is scary. Maybe you've heard of Shodan before; I know I hadn't. 

Shodan (if you don't want to track this down) maps physical computers connected on the Internet. Think of it as search for computers rather than web pages. This makes it the tool of choice for finding, say, routers with the default login/password still set. Then you know which IP addresses to mount an attack on.

Scary stuff. 

Fact is, there are a zillion ways for the Bad Guys to attack you. One thing you can do (in addition to using Shodan to search your own net for unprotected hardware) is to consider using CodeMeter to ensure code integrity on your embedded systems. In addition to preventing software theft or reverse engineering, encrypting the code with AxProtector and requiring CodeMeter to decrypt it prevents any bits from being changed. Unless the code remains unchanged it won't decrypt. So no chance that an intruder can install any malicious payload.

CodeMeter lineup

 

Here you can see some of the different (non USB) form factors including PC Card, PC Express, SD, Micro SD, and Compact Flash. You can also get CodeMeter on an ASIC wafer or a wee small board to solder into your system. Most of these are optionally available with additional flash RAM--up to 16GB for some.

All these are functionally the same: they all have the SmartCard chip, our firmware, and memory and they all work exactly the same on Windows, Linux, even VxWorks. Of course we support MacOS but that's not applicable to embedded applications that I'm aware of.

For more information on all the CodeMeter variants click the button below.

Download the CodeMeter poster

Topics: Code Integrity, CodeMeter

Software security and code integrity

Posted by John Browne on Mar 28, 2012 11:37:00 AM

Hackers are out there. So you can't take for granted--now or ever--that it won't happen to you. Achieving software security is a complex problem; what's amazing to me is how often the bad guys get in because someone left the door unlocked. SQL injection attacks, for example, should NEVER happen but they do, and with big consequences.

There's another aspect to software security that's frequently overlooked. If you're distributing application code--executables--how can you be sure that what your user is getting hasn't been tampered with?

How could that happen? Obviously one way is through counterfeiting. A company purports to be a legitimate reseller of your product, but what they're really selling is a cracked version with some malware injected. Like a keystroke logger. Another possibility is you have a freely available demo or trial version with no copy protection (after all, you want people to try it and share it). But a copy with malware starts circulating.

Finally, in critical areas like health care, aviation, or EMR systems you need to be able to assure the users of perfect code integrity all through the distribution pipeline. Anything that can compromise software security of systems with potential life-threatening consequences for failure must be eliminated.

One solid, easy-to-implement method to increase software security ensure code integrity is, of course, to deploy CodeMeter. With either a CmDongle (maximum software security) or CmAct (very strong security). With CodeMeter even changing a single bit in the protected executable will prevent the application from running. If it runs, you know you have perfect code integrity from the software developer to the end user. Software security doesn't get any better than that.

Topics: Code Integrity, CodeMeter