Wibu-Systems Blog

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

Anti-Piracy, Flexible Licensing and software monetization

Posted by Terry Gaul on Sep 17, 2015 11:03:39 AM

We’ve all seen the disturbing software piracy statistics released by BSA | The Software Alliance in their Global Software Survey:

  • 43 percent of the software installed on personal computers globally in 2013 was not properly licensed
  • The global rate at which PC software was installed without proper licensing rose from 42 percent in 2011 to 43 percent in 2013 as emerging economies where unlicensed software use is most prevalent continued to account for a growing majority of all PCs in service.
  • The commercial value of unlicensed PC software installations totaled $62.7 billion globally in 2013.

These trends are sure to put a dent into any ISVs bottom line. In their blueprint for reducing software piracy, the BSA points to increased public education and awareness, modernization of IP laws, and stepped-up enforcement with dedicated resources as important steps towards thwarting piracy.

Of course, a more immediate approach to preventing piracy is to integrate copy protection directly into the application with a robust software protection solution like Wibu-Systems’ CodeMeter. It takes just minutes to protect software from illegal copying, reverse engineering or tampering without having to change a single line of source code.

In addition to preventing software piracy and hacking, a sound monetization strategy will serve to maximize ISV revenues as well. With secure, flexible licensing capabilities, ISVs and device manufacturers can effectively implement creative licensing strategies to meet the dynamic market requirements of their end users. The days of the perpetual software license are long gone and ISVs need the ability to introduce various pricing schemes based on pay-per-function, pay-per-use, subscription, or other possible licensing options. A representative example of a flexible licensing system is CodeMeter License Central, which enables ISVs to create, manage and distribute all types of licenses in a secure, straightforward manner.

Industry analyst firm, Frost and Sullivan, concluded in a white paper that “customers experience best long-term value in terms of both top-line revenue realization bottom-line costs and efficiency when license management solutions inherently provide comprehensive functionality and robust security.”

Download Frost and Sullivan Whitepaper

I invite you to download the full whitepaper, entitled Best Practices in Software Monetization: A Customer-Centric View of Secure License Management. The White Paper sheds light on various aspects of successful software monetization strategies, ranging from business-enabling licensing architectures to resilience against hacking. The document demonstrates how changing times demand that ISVs implement customer-centric business models and customer-friendly enforcement in order to increase their top line software revenues while controlling bottom line costs.

   

Topics: License Management, software protection, CodeMeter, secure licensing, software piracy, CodeMeter License Central

Making the Case for Medical Device Software Protection

Posted by Terry Gaul on Feb 13, 2014 10:50:00 AM

sirona 01Former U.S. Vice President Dick Cheney acknowledged that he once feared that terrorists could use the electrical device that had been implanted near his heart to kill him and had his doctor disable its wireless function. The device in question was a defibrillator that could detect irregular heartbeats and control them with electrical jolts. Cheney had his doctor turn off the device’s wireless function in case a terrorist tried to send his heart a fatal shock.

Medical devices used for critical care are becoming increasingly reliant on software and securing that software from tampering and malware has become a critical consideration in the development process.

Even so, software security remains an afterthought in some medical device design, according to researchers from Carnegie Mellon who are working towards evaluating the software security of medical devices. In their paper, “Take Two Software Updates and See Me in the Morning: The Case for Software Security Evaluations of Medical Devices,” Steven Hanna, University of California Berkeley, et al, notes that medical devices are susceptible to malware because:

1. Software in medical devices is becoming increasingly complex.

2. More and more medical devices are becoming networked with wireless Internet connectivity.

3. More medical devices are evolving from electro-mechanical to software-controlled devices.

4. Analyzing security after a potential risk becomes a tangible threat would be too late for effective deployment of defensive technology.

In their study of an Automated External Defibrillator (AED), they identified security flaws in both the embedded software and the commercial off-the-shelf software (COTS) update mechanism. They concluded that manufacturers of medical devices containing software should have plans for assessing specific security risks, detecting security compromises, and recovering from computer security incidents—especially if the manufacturer plans to use wireless communication or Internet connectivity that would increase the device exposure to the risks of malicious software.

After becoming aware of cybersecurity vulnerability and incidents that could directly impact medical devices or hospital network operations, the FDA is recommending that medical device manufacturers and health care facilities take steps to assure that appropriate safeguards are in place to reduce the risk of failure due to cyber-attack, which could be initiated by the introduction of malware into the medical equipment or unauthorized access to configuration settings in medical devices and those connected to hospital networks.

They further stated that manufacturers are responsible for remaining vigilant about identifying risks and hazards associated with their medical devices, including risks related to cybersecurity, and are responsible for putting appropriate mitigations in place to address patient safety and assure proper device performance.

At Wibu-Systems, we are providing the tools that enable embedded software developers to protect medical devices. The term “Integrity Protection” encompasses security measures, namely protection of system resources, programs and data against unauthorized manipulation, or at least identification and display of such modifications. The challenge consists in guaranteeing data integrity, and, if not possible, bringing the system to a safe mode and stopping the execution of any function.

We’ve demonstrated that the best integrity protection solutions are based on cryptography and associated security mechanisms, such as digital signatures and message authentication. With our CodeMeter licensing and protection platform, we provide a smart-card-security-based protection system, which is available for industrial interfaces. By utilizing CodeMeter, you can secure a device so that it only receives software updates from the device manufacturer. When the device is started, integrity checks are performed to be sure that the software being run is authenticated and not some type of virus.

CodeMeter supports common operating systems like Windows, Mac OS X, Linux as well as Windows Embedded, Embedded Linux, RTOS like Wind River’s VxWorks and PLC development software like CODESYS and more. It contains a secure implementation of symmetric and asymmetric encryption methods (AES, RSA, ECC), functions for signature validation (ECDSA) and a random number generator, according to FIPS140-1 and fulfilling EAL 4+ (Common Criteria Certified). CodeMeter includes all the available tools needed to implement all of the steps described above for integrity protection, software protection and the prevention of code tampering of embedded medical devices.

 

Download the White Paper: Integrity  Protection for Embedded Systems

Topics: CodeMeter, software protection, embedded security

Advantages of the CodeMeter Runtime

Posted by John Poulson on Jun 19, 2013 5:22:00 AM

I was recently asked why Wibu-Systems requires the installation of a CodeMeter "Runtime" on the end user's computer. There is one big misconception and several undocumented advantages that need to be explained. When one's goal is to provide the most secure software monetization system on the planet, one needs at the very least, to establish an encrypted communication channel between the protected application and the license container (dongle or software license). This is the fundamental reason we included the runtime option as a basic part of our architecture.

Misconception: The Installation of our Runtime is REQUIRED

CodeMeter Control Center Runtime icon in the Windows System Tray

The presence of the CodeMeter icon in the Windows System Tray is one way to determine the presence of the Runtime.

One of the misconceptions about the CodeMeter System is that it needs a "Runtime" in order to operate. This is not the case. The (highly flexible) CodeMeter System allows the ISV to integrate CodeMeter protection and license management features into the protected application in any number of creative ways. For example, ISVs can (in Windows):

  • Install standard runtime as an MSI module
  • Install standard runtime as a merge module
  • Install "silently"
  • Install as a Windows service
  • Simply copy CodeMeter.exe in the same directory as the installed program
  • Use the new CmCompact option
  • Use our custom CodeMeter Runtime Bridge
  • Incorporate our driver as source. We can supply this as a static library or as actual source code.

Each of these methods has its own set of advantages and disadvantages. For example, if you use the driver source code option, certain CodeMeter license handling features are disabled. With all these options available, why should you go to the trouble of seeing that the standard runtime gets installed in the suggested manner?

Answer: There are many technical and business flow reasons for a runtime. While I can’t list them all, a few appear below. We also feel that any license management company that wants to provide basic security is simply being lazy if they don’t provide a runtime.

Top Ten Reasons for providing a Runtime

Our customers gain several advantages by using the runtime in the manner we suggest. These advantages bring cost savings, higher security and less headaches. The top ten advantages are:

  1. We can quickly adapt to changes in operating systems without requiring that our customers download patches and recompile their software.
  2. The runtime includes the ability to create error log files and other diagnostics.
  3. The integration of networked licenses is simply one click away.
  4. The runtime knows how to handle virtual machine environments.
  5. The runtime knows how to handle terminal servers.
  6. The runtime maintains an encrypted communication channel between the protected application and the license container.
  7. The runtime keeps track of concurrent licenses; those in use and those that are idle.
  8. The runtime can simultaneously handle access from many DLLs in one process.
  9. The runtime can handle many executables from one ISV.
  10. The runtime can handle many different executables from many different ISVs.

As you can see from the above list, the advantages of a runtime environment far outweigh any perceived disadvantages. We will continue to improve the CodeMeter runtime and will continue to suggest that best practices include the installation of the runtime on the end user's system. We also suggest to the end user that he/she update the runtime on a regular basis.

See how easy it is to protect your software with CodeMeter. Watch our three-minute demo!

Watch the 3 minute demo!

 

john poulsonJohn Poulson has worked in the software protection industry since 1988 and has been with Wibu-Systems since 2000. He is an expert in license authentication best practices and deep powder skiing.

Topics: CodeMeter, software activation, software protection, software licensing, secure licensing

Breaking Enigma – 80th Anniversary

Posted by John Poulson on Dec 13, 2012 6:02:00 AM

For software developers concerned with preventing software piracy or enforcing licensing policies, there is a great lesson to be learned from events that took place eighty years ago this month.

The Enigma cipher machine was invented by a German engineer (Arthur Scherbius) just as World War I was coming to an end. The machines were used for commercial purposes throughout the 1920s but as Germany began to re-build its military forces in the 1930s a secure form of communication was needed. The German government looked to the Enigma cipher machine as the answer.

German Military Intelligence relied on the mathematics of the Enigma machine for securing their sensitive military and diplomatic communications. Consider the design of the machine and the possibilities and combinations of this clever electro-mechanical device and you will come to understand why they were confident in its use.

An Enigma cipher machine consisted of five variable components:

Enigma Diagram

Enigma wiring diagram with arrows and the numbers 1 to 9 showing how current flows from key depression to a lamp being lit. The A key is encoded to the D lamp. D yields A, but A never yields A; this property was due to a patented feature unique to the Enigmas, and could be exploited by cryptanalysts in some situations.

Picture courtesy of Wikipedia

  1. A telephone operator style plug board containing up to thirteen dual-wired cables.
  2. Three ordered (left to right) rotors which wired twenty-six input contact points to twenty-six output contact points positioned on the opposing faces of each rotor.
  3. The rotors also contained twenty-six serrations around the circumference of each rotor allowing the operator to specify an initial position for each rotor pair.
  4. A moveable ring on each rotor which controlled the rotational behavior of the rotor to the immediate left by means of a notch.
  5. A fourth half rotor that “reflected” the input and outputs to the same face of contact points.

Dr. A Ray Miller, PhD wrote a paper about Enigma (date unknown), which was published by the Center for Cryptologic History (part of NSA), located at Fort Meade, Maryland.  In the paper he disclosed for the first time the mathematics behind the typical Enigma machine used by the German Army (the German Navy had added a fourth rotor to their machines enhancing the encryption). Considering all of the possible rotor positions, the possible plug board options and the position of the notched rings, Dr. Miller calculated that the total possibilities Allied cryptanalysts were typically faced with during most of the Second World War when attempting to “read” Enigma traffic was:

                107,458,687,327,250,619,360,000 (approximately 1023) or… stated another way it is about one hundred thousand billion billion.

With such daunting odds on their side, it is not surprising that German cryptographers felt secure in using Enigma. They had on their side the strength of large numbers, numbers so vast they are really beyond comprehension. And in that misplaced confidence, the Germans of that era were absolutely, completely and fatally wrong as three Polish cryptanalysts proved eighty years ago this month.

Historians may continue to argue over the military value of the decrypted communications. What cannot be argued is the incredible engineering feat performed by Marian Rejewski , Jerzy Rozycki and Henryk Zygalski of the Polish Cipher Bureau when they first broke Germany's military Enigma ciphers in December, 1932. Then just five weeks before the outbreak of World War II, they presented their Enigma-decryption techniques and equipment to British military intelligence. Throughout WWII, Allied Intelligence used information decrypted from German military communications very sparingly. They wanted to prevent the Germans from learning that their codes had been compromised. The fact that Enigma had been broken was not generally disclosed until the 1970s.

The breaking of the Enigma Cipher machine is an object lesson for software developers today. And is one that has not been lost on the development team at Wibu-Systems. While the CodeMeter encryption system used by Wibu-Systems incorporates the AES algorithm and Elliptical Curve Cryptography coupled with RSA for asynchronous key exchange and should be mathematically impossible to crack using brute force; the software engineers and developers at Wibu-Systems constantly make improvements to the basic CodeMeter architecture and security algorithms. Because it is a fact of life that whatever can be engineered… can be reverse engineered.

CodeMeter SmartBind is Wibu-Systems' newest technology to determine whether a software activation is valid or not by using internal heuristics. With SmartBind, you don’t have to worry about the details of which hardware aspects of your customer’s computer might change. The algorithm takes care of it for you.

Download the FREE whitepaper

john poulsonJohn Poulson has worked in the software protection industry since 1988 and has been with Wibu-Systems since 2000. He is an expert in license authentication best practices and deep powder skiing.

Topics: CodeMeter, cracking, software protection

Software protection dongles and embedded systems

Posted by John Browne on Jun 13, 2012 4:58:00 AM

There are plenty of reasons to use a software protection dongle even when you're running an embedded system. Some people believe that embedded systems are immune to piracy because the software has to be tied to a specific piece of equipment. 

Embedded system with CodeMeter software protection dongle

But piracy may not be the primary concern for embedded systems; theft of intellectual property is. Increasingly today the machine is only a tool; it's the IP that the machine uses that has huge value. After all, a competitor can take your machine apart and see how it works. From that information they can build a competitor, knock-off, or even possibly improve on it. However, the software that makes the machine really valuable is a different matter.

We're finding an increased interest in using CodeMeter as a protection device for IP--basically the customer uses a CmStick or CmCard with additional flash RAM and stores their IP on the RAM in encrypted form; only the presence of a valid license will decrypt it.  Further, a password can be placed on the CodeMeter software protection dongle preventing access in the event it falls into the wrong hands. That's two factor authentication. 

A typical use for this is commercial weaving systems that make polo-style shirts or tee shirts. The patterns and/or embroidery on those shirts may represent valuable IP (for example, the pattern to make a logo). Preventing the data from falling into the hands of counterfeitors makes it harder for fake shirts to be produced. In this case the CodeMeter software protection dongle can store not only the programs to drive the weaving machine but also the IP in the form of designs or logos. 

Above is a picture of a Beckhoff CX1010 industrial PC with a CmStick (USB) and a separate CmCard (CF). This device can run either Windows Embedded or Windows CE.

Topics: dongles, software protection

Bittorrent vs software protection

Posted by John Browne on May 15, 2012 6:22:00 AM

Microsoft is trying yet another approach to end P2P file sharing of their software. Ironically it involves them investing in a Russian startup aimed at blocking bittorrent traffic by creating confusing false connections. 

The only problem is it doesn't work. Well, not very well at least. They were able to block 42,000 downloads of this blockbuster. But it will cost (between $12,000 and $50,000 --dollars, nyet?).

The other problem is this tune's been sung before. (Great read, BTW, especially where they got hacked by some high school kids.) Different methods (not very good, actually) but same general idea.

This is no way to achieve software protection. This is akin the scene in Blazing Saddles where they fool the bad guys into attacking a fake town.

Microsoft and other publishers should spend their time focusing on how to make it tougher to copy their software in the first place, not how to keep cracked software from being shared. 

Topics: Copy Protection, Anti-piracy, software protection