Wibu-Systems Blog

John Browne

Recent Posts

Firmware 2.0 released for CmSticks

Posted by John Browne on Aug 14, 2012 12:57:00 PM

Lots of new stuff coming down the pike this summer! Another brief post here to update you on version 2.0 of our CmStick and CmStick/M firmware (in case you're not totally up to date with our naming conventions "/M" means a CmStick with additional flash memory). This update only applies to newer CmSticks with part numbers 1001-02-xxx and CmStick/M with part numbers 1011-02-xxx (see close up of back below):

CmStick back side showing part number

We made three important improvements with this version (see below for how to update). 

  1. Most important one first: now future firmware updates (like 2.0.1 if we do it) can be made more simply over large deployments of CmSticks, as in an enterprise setting. Before V 2.0, each CmStick required a separate and unique update file. Now, however, we've switched to PKI (public key infrastructure) so all CmSticks can share a single update file without compromising the security of the update process. 
  2. Next is improved RSA security--the CmSticks now support both 1024 and 2048-bit RSA keys. This is already supported in the CodeMeter API, so you can implement immediately if you need to.
  3. We increased the reliability of the hardware by the addition of some new memory correction mechanisms. Sometimes when the dongle is suddenly removed from the USB port or loses power during a write operation you can corrupt memory (note this is extremely rare but it does happen). Same thing can happen if you have a lot of write ops over a short time. These are now more reliable which will cut down on user problems as well as extend the lifetime of the CmSticks. 

How to update? Here's a short video on how to do it. It's really quick and simple (it does require Internet access--if there's no access on the computer it's usually plugged into, remove it, install it in a connected computer, and update there). Embedded video too small to read? Click the youtube button to enlarge.

Topics: CodeMeter, Wibu-Systems news, Wibu-Systems USA

License Central 1.51 released

Posted by John Browne on Aug 7, 2012 2:23:00 PM

Just a quick note to tell you that we've released version 1.51 of CodeMeter License Central.

What's new:

Windows 8: this release completes our support for Windows 8 with the addition of CmActLicenses in the "supported OS" screen. 

License Central 1.51

So now you can use either CmDongle or CmActLicense for your Windows 8 applications with this release of CodeMeter License Central (it was possible earlier but you had to use CmBoxPgm to create the licenses and activation schemes). Notice also we have full support for Windows Server 2012. Now you can test creating licenses for your protected applicaitons using License Central with your beta or pre-release copies of the next Microsoft operating systems.

Individual License Activation: When you go to the depot and click on a ticket with multiple licenses, you can select which of those to activate if you don't want to activate all at once:

CodeMeter License Central

 

 

In addition to these improvements, we also fixed some bugs (yes, we have bugs too). You can see which ones by looking at the change log. As always, download the latest versions of CodeMeter software here.

Topics: CodeMeter, License Management, CodeMeter License Central

Secure Software Licensing Part 3

Posted by John Browne on Aug 2, 2012 3:42:00 AM

If you've been following along up to now you'll be familiar with what we mean by "software" and also "secure." That leaves perhaps the most mis-understood term, "licensing." Let's look at that today.

I have in my wallet a driver's license, which gives me the right to drive a car in those jurisdictions that recognize its validity (currently all of the United States and many other parts of the world). Along with that right is a restriction to obey the laws governing motor vehicle use. Right now my license says I can drive a non-commercial vehicle as long as I'm wearing my glasses but I can't ride a motorcycle anymore.Keyring

When you buy or sell software, you don't really get to "own" but instead you get a license that allows you to use it under the restrictions that are in place. These restrictions are usually spelled out in legalese in a document called an End User License Agreement or EULA. 

Now in a perfect world that document would be all we need to make sure no one violated our license agreements. But it's not a perfect world.

Besides, we want to have licensing rules that optimize our business model. So some of the licensing that might be interesting includes:

  • Pay per user: the most traditional style--each user pays for a license and they can use the software in perpetuity.
  • Pay per time (subscription): More normal with SaaS software, but with the right licensing system this is easy for desktop applications as well. 
  • Pooled or floating licenses (concurrency): You have a block of licenses (say 10 for example's sake) and they can be used by anyone on the network until all 10 are in use. The next person who wants one has to wait until a license is freed up by someone exiting the program. 
  • Pay per use: In this model, each time the program is run there is a fee required. For simplicity's sake you can sell blocks of usage credits in advance; the licensing system has to decrement those credits each time the software is run. 
  • Pay per feature: Perhaps the most obscure of all, and normally the most difficult to implement. In this model, some aspects of the software are metered by their own licenses. A trivial example would be a program that charges extra to save a file or print a document. 
  • Maintenance period: Many ISVs charge a separate maintenance fee to customers to cover the cost of support and any releases that ship during the contract period (typically a year at a time). With maintenance period licensing, you can simplify ensuring that only customers currently under contract can run the releases.
  • Trial and/or demo versions: A trial is typically a full version but time limited. A demo is frequently a crippled version with some functionality removed (like saving data or work). Either should be easily enabled by a licensing solution without you having to branch your code and develop new stuff.
  • Internet activation: Your customers should be able to buy, download, and activate their software over the Internet without jumping through a lot of hoops. You, as the ISV, should be able to offer this via an ecommerce website that easily connects to your license management system, your back-end systems like ERP and CRM, and to your application with minimal fuss and bother. A good license management system will handle this for your via XML/SOAP web services.

Again, if all we had was a EULA to enforce these models we'd be out of luck; too many people are willing to violate these licensing agreements, as the BSA knows all too well. So we need a "secure software licensing" system that provides the security to enforce the license rules and restrictions. CodeMeter is designed to do just that. 

Topics: License Management

Secure Software Licensing Part 2

Posted by John Browne on Aug 1, 2012 4:46:00 AM

In the last blog post, we talked about what is meant by "secure" in the phrase "secure software licensing." But what exactly do we mean by "software?"software

At first blush I think most of us think of "software" as a desktop application like Photoshop or perhaps an OS like Windows. And frankly this is the bulk of what we see people needing advanced secure software licensing for. But wait, as they say, there's more:

  • Executables: Anything in the PEF (portable executable file format) can be protected against license abuse or copying. 
  • DLLs: dynamic-link libraries (DLLs) and shared libraries on MacOS and Linux can be used to store a significant amount of protectable code. 
  • Data files: files associated with particular applications may need to be protected as well. For example, PDF files (used by Adobe Acrobat) are a popular format for distrubuting electronic documents, some of which can contain sensitive information. You might want to secure the availability of these to certain people or certain time frames. Additionally, if your application uses a database of proprietary data (perhaps industry benchmarks you have painstakingly collected over the years) you might want to prevent unauthorized access or copying of that data.
  • Media files: Both music and video have multiple DRM systems in place for commercial distribution. But what if you want to stream video from your website but limit its distribution to a set of license rules? This can be difficult without a secure software licensing system. 
  • Website access: As more and more applications move into the cloud, or are presented as Software as a Service (SaaS) like salesforce.com, access control and authentication become more and more important. Current systems like named users with passwords are ripe for abuse (sharing credentials among multiple users). 
In the next article I'll dig into the term "software licensing" to discuss what is arguably the most interesting part of this concept.

Topics: License Management, Copy Protection, Anti-piracy, software piracy

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

AxProtector 8.20 Released

Posted by John Browne on Jul 18, 2012 10:30:00 AM

Following up on yesterday's post on CodeMeter 4.50, here's some information about the rest of the release.

Swiss Army Knife

AxProtector has some new features and fixes, including the following:

  • You can use WUPI (Wibu Universal Protection Interface) API calls with .NET now when programming in mixed mode. WUPI was always available for .NET and other languages, but mixed mode wasn't supported before 8.20. 
  • You can also use individual method encryption in mixed mode using IxProtector. This is also new in 8.20. Note: this is currently done using an XML file; support for specifying individual methods in the graphical user interface will come in a subsequent release. The XML file is only used when you are doing mixed-mode programming; for native .NET or C++ you can still use the GUI as before.
  • If you select the "-cac" option (System Time Check) we will only check the Certified Time Server if the license uses a time restriction (e.g., Expiration Date or Usage Period).
  • You can now add code integrity checking to your executable, DLL, or dylib (Windows and MacOS X) by checking the "-cav" option. This creates a signature on the code which is verified at runtime. This replaces the old "virus check" option.
  • Bug fixes and general security improvements. These are detailed in the release notes.
AxProtector is still your best choice for undefeated software protection against piracy, inadvertent license abuse, reverse-engineering, and tampering. If you haven't tried it yet, be sure to click on the link to get your copy of the evaluation system. 

Topics: AxProtector

CodeMeter 4.50 released

Posted by John Browne on Jul 17, 2012 2:45:00 PM

Just a short note to let you know CodeMeter 4.50 has shipped and is available for download here.

CodeMeter 4.50 fully supports Windows 8 for both CmDongle and CmActLicense. 

Other enhancements:

  • License tracking is now supported via an optional log file from CodeMeter. The logfile provides basic license utilization data for reporting and analysis via 3rd party tools. See the CodeMeter User Help for information on how to turn this on and configure it.
  • You can now specify a minimum license server version for all CmActLicense programming operations.
  • CmActLicenses can now be locked via the certified time server just like CmDongles.
  • License Information Files (*.wbb) are now universal: the same file will work on all supported operating systems. Older .wbb files will work on Windows 8 and Windows Server 2012.
  • All Unit Counters are now 32-bit values, on both CmDongle and CmActLicense.
  • Sessions via Remote Desktop can no longer access local licenses. If a customer needs to run Remote Desktop they will need a network license.
  • Options now exist for you to streamline the installation of the runtime. For example, you can install it with no user interface. See the CodeMeter Developer's Guide for more info.
We also released an updated version of AxProtector; stay tuned for some details later on that as well.

Yet more software license management flexibility

Posted by John Browne on Jul 12, 2012 4:55:00 PM

Time for some how-to.

You don't have to use an API to implement CodeMeter--in fact, you can just use AxProtector (Automated Executable Protection) and wrap your whole executable (or dll or file or what have you, but we'll focus on executables in this blog post) with strong encryption that needs a valid license at runtime. Badda bing, badda boom. You're done.

That was easy.

And you can get a lot of flexibility in your software license management with no more work. Time based licenses, usage-based, network, concurrency, all those things and more are available with no source code changes--just protect with AxProtector and then set the licensing rules when you create the license.

So why mess with the source code? Good question. There are two reasons:

1. You can turn on or turn off individual functions or methods with separate licenses, thus enabling a pay-per-feature business model. This can be really cool if you think about all the possibilities (more later).

2. You can increase the security of your application, since multiple licenses with multiple separte keys are needed for it to run. While cracking CodeMeter is no small feat, this will just make it that much tougher.

How hard is this source code intergration? Pretty basic. We have a low-level API (the "Core API") which you don't repeat do not want to use. If in doubt, please give us a call to ask if you should use this. Normally our customers only use it when they need to implement CodeMeter on a platform we don't yet support. 

These are not the functions you are looking for...

The one you want is WUPI (Wibu Universal Protection Interface). WUPI is a high-level encapsulation of the Core API and by using it you will avoid shooting off your toes the way you can with the Core API. WUPI will do most anything you need to do.

WUPI only needs 15 functions to cover the whole gamut of stuff:

  1. Accessing: allocate and free a license; get a handle to a license
  2. Encryption: Encrypt and decrypt code
  3. Manage: Decrease Unit Counter; Get License Type; Query info; Read/write data
  4. Security: Debugger check and license check
  5. Errors: Get last error

That's it. Most of it you don't need to worry about. All the functions return either a BOOL or an INT, which makes them easy to use in a number of programming languages.

Parking meter

Integration couldn't be easier. There's an include file (we're talking C++ now), and you have to point your linker to some libs. The CodeMeter API guide (accessed from the CodeMeter Start Center, which is part of the Evaluation System) gives you sample code to cut & paste.

Here's an example:

#include <WibuIxap.h>
 int iWupiResult = WupiCheckLicense(0);
 if (!iWupiResult)
{
// License check failed.
}
else
{
// Successfully checking license.

That's it. Pretty simple--you just need to wrap these kinds of calls around the code that does stuff inside your application. 

Suppose, for example (and I know this is a trivial example) you wanted to meter printing. You could wrap your print function with a call to decrease the CodeMeter Unit Counter:

#include <WibuIxap.h>
 
int iWupiResult = WupiDecreaseUnitCounter(0, 0);
 
if (!iWupiResult)
{
// Unit Counter reached 0.
// License isn´t available or already allocated.
}
else
{
// Successfully decreased Unit Counter by the specified units.
// No Units remaining.
}

 If you use some counter in your code for the number of pages as a parameter to the WupiDecreaseUnitCounter() function, you can meter things exactly. Unit Counter values are set at license time, so this would require you to sell "blocks" or pages to be printed; when they get low on available pages (ie UnitCounter value) the system will let them know that they might want to buy some more. When they are gone, no more printing.

Printing is trivial (well, perhaps not if you're a printer) but there are plenty of other things you could wrap in this kind of protection. Perhaps you want to have Bronze, Silver, and Gold versions of your product. The normal way you'd do that is to branch your code or use conditional compiles. But it's a lot of work. With WUPI you can build one monolithic application, wrap that Bronze, Silver, and Gold functionality in separate license calls, and ship the whole thing to everyone. They get the product they paid for (because the correct license turns things on). Nothing more.

One last thought. This API stuff is not needed if you use .NET; because it's managed code you can actually protect individual .NET methods from inside AxProtector. 

photo credit: lakewentworth via photo pin cc

Topics: CodeMeter, License Management, AxProtector, Software Development

Software license management flexibility

Posted by John Browne on Jul 10, 2012 2:28:00 PM

Here's a great post about the problems software license models can create for researchers. Short version is that most commercial software licenses restrict the usage on massively parallel systems so that researchers can't take advantage of them without buying zillions of licenses, which, of course, isn't going to happen. 

Open source software is one solution to the problem, since it's not metered and thus not restricted. But (and this is no slam on OS software) sometimes the commercial stuff is better. Just is. Or it's what the researcher is already using, and converting to a different platform isn't feasible.

So they're stuck, and the problem has to chug along on one core forever instead of getting solved quickly on the parallel system.

Waiting for the program to finish.

How did we get to this mess, anyway? Commercial software vendors (ISVs) have struggled with the conflict between traditional licensing models and new computing ones. Back when computers were basically one core, one user, one desktop it all seemed so easy. Just ship great software and don't worry about the license. But multi-core processors, and multi-processor servers, and now cloud services with varying numbers of virtual machines instantly available as a scalable deployment--suddenly it all got a heck of a lot more complicated. If a user was running on an 8-core machine, should they pay more for the license than a user running on a single core?

ISVs reacted by metering stuff they could: number of cores, number of physical processors, speed of the processor, restricting or preventing VM use, and so on. This certainly didn't endear them to their customers, who saw (mostly anyway) these capabilities as allowing them to get more computing bang for the buck. 

Unfortunately their software license management systems kept getting in the way of finding metering solutions that allowed them to map true value to revenue. They metered what they could; not what necessarily made sense (this is granting them the benefit of the doubt--I hope they didn't just ignore customer input about how to best license under emerging computing paradigms). 

One thing we've always tried to do with CodeMeter is provide for virtually unlimited flexibility in license models: we like to think if you can dream it up we can implement it with the existing system. We've made some improvements over the last year to handle the new virtuality reality and we will continue to exhance the products in this area in the future. We're extremely interested in hearing from customers on these issues to make sure we're working on what you need. So if you have some thoughts about how you'd like to be able to license and/or meter your software, please pick up the phone and give us a call. 

Topics: License Management

RSA cracked; CodeMeter still secure.

Posted by John Browne on Jul 5, 2012 4:56:00 AM

The big news for crypto-wonks this week is that an international group of researchers has cracked a portion of RSA encryption. And it's not like they had to throw supercomputers at the problem; it was cracked in under 15 mintues. You can read the whole paper here (note: not light reading).

cracked safe

Mostly they were interested in hardware tokens using RSA to see if they could reveal the the secret key with "padding oracle" attacks (using error messages as a side channel). Some of these tokens use SmartCard circuits so the assumption is that the key is completely safe. 

The devices they cracked were (and the time required):

  • Aladdin eTokenPro (21 minutes)
  • Gemalto Cyberflex (92 minutes)
  • RSA Securid 800 (13 minutes)
  • Safenet Ikey 2032 (88 minutes)
  • Siemens CardOS (21 minutes)

CodeMeter, of course, uses a SmartCard chip as its core. So is there a concern?

The good news is no. No worries. CodeMeter doesn't rely on RSA for encryption, although we make it available optionally for those customers who want to use it. CodeMeter uses AES 128-bit for basic encryption and ECC for encrypting the communication channel between the hardware and the operating system

By the way the researchers asked the manufacturers of the cracked tokens for a response. The most common one was along the line of "Oops."

Topics: CodeMeter, cracking