I have to work with an HSM device for security requirements in my project. I am confused about how HSM is interfaced with C on a Linux machine.
How does a user access HSM internal memory for performing different operations with it?
Every HSM vendor supports at least one cryptographic API. PKCS#11 is a particularly common choice, but there are many other options. OpenSSL, for example, supports HSMs through an engine interface.
Often the vendor will expose a proprietary API in addition to the "standard" APIs it implements. The proprietary API typically offers a greater degree of control over key security properties and key usage than is possible to express in the standard APIs.
When using an HSM, one typically issues a command to load a key from a secure store and retrieve a handle to the key object. This handle is the layer of abstraction that allows the HSM to perform the key operations securely without exposing the key material.
With regards to your project, it is important that you don't simply "shove" the HSM somewhere in your solution to make it appear secure. Instead, think long and hard about the security properties of your system and how cryptography may help you defend against attacks. Once you've identified your attack vectors (and your associated cryptographic defences), then consider which cryptographic API can support your use cases. Only then should you select the best vendor from those who support that API.
In my experience, the standard APIs only suffice for simple security systems. For complex projects, it's almost always necessary to work with the proprietary API of a particular vendor. In such cases, lean heavily on the vendor for support and proof-of-concepts before settling on a product that truly meets your needs.
I know this is a year old, but in case someone else runs across it, there is a more detailed discussion at this link:
Digital Signing using certificate and key from USB token
Including some long-form working code that I added. You are also welcome to get my code directly at this link: https://github.com/tkil/openssl-pkcs11-samples
Good luck!
The HSM vendor should have provided you a library. You can use this library to interact with your HSM via PKCS#11 interface. You will need the PKCS#11 header files in you project in order to do that.
Check out this site http://www.calsoftlabs.com/whitepapers/public-key-cryptography.html to get a introduction
i want to sell one program to customer， but I want to make one program can run at one server with only one lisence code, if customer want to run the program at other servers, he needs to buy more activation codes.
so is there a good method to generate activation code? i imagine that it will be related with one password and server mac-address
BTW: I just need one easy method, because my customer is not technology man
I can give you a rough idea, but, it isn't very easy.
Have a server running, and, at the start of your program, make it query your server with an activation code and a generated hash code (that is unique to each compile of the program) and have your server check if the combination has been queried before.
There are well-established solutions for [product activation][2], and they already deal with the issues you need to think about, including:
Securely activating licenses on systems without an Internet connection
Allowing users to securely relocate licenses
Allowing installation on virtual systems without enabling unlimited copying
When a user's system crashes, how you get their license up again on another system.
Protecting against various hacking attacks
What to use for locking? And as Alex says, the MAC address is not a good choice, even if it has been a common one. A combination of systems parameter is best, but then how do you deal gracefully with a user who does a minor system upgrade?
Secure trial licenses, whether time-limited, function-limited, or indeed both.
Configuring product features
Licensing upgrades...
....and much more.
There is no perfect way to do this since virtualization can basically emulate any environment to amazing detail. License files, signed executables, and remote license servers are all options but are such a strain on your customer. I recommend you form a license agreement with your customer and trust them. There is no reason that you couldn't adopt some sort of periodic audit but in the end it comes down to a matter of trust vs convenience.
I have a Silverlight app that connects to a php webservice. I want to encrypt the communication between the webservice and the Silverlight client. I'm not relying on SSL. I'm encrypting/decrypting the POST string myself using AES 256bit Key and IV.
The big questions then are:
How do I generate a random unique key/iv pair in PHP.
How do I share this key/iv pair between the web service and silverlight client in a secure way.
It seems impossible without having some kind of hard coded key or iv on the client. Which would compromise security.
This is a public website, there are no logins. Just the requirement of secure communication.
I can hard code the seed for the key/iv (which is hashed with SHA256 with a time stamp salt and then assigned as the key or iv) in PHP source code, that's on the server so that is pretty safe. However on the client the seed for the key/iv pair would be visible, if it is hard coded.
Further more using a time stamp as the basis for uniqueness/randomness is definitely not ok, since timestamps are predictable. It does however provide a common factor between the C# code and the PHP code.
The only other option that I can think of would be to have a 3rd service involved that provides the key/iv to the Silverlight client, as well as the php webservice. This of course start the cycle anew, with the question of how to store the credentials for accessing the key/iv distribution service on the Silverlight client.
Sounds like the solution is then asymmetric encryption, since sensitive data will be viewed only on the administrative back end of the website. Unfortunately Silverlight has no asymmetric encryption classes. The solution? Roll my own Diffie-Hellman key exchange! Plug that key into AES256!
The answers to your questions are: "SSL".
Symmetric encryption expands a shared secret of relatively small size (e.g. a 256-bit key) into a secure data transmission tunnel which ensures confidentiality and integrity. This is not as easy as it may seem; there are many small but deadly details.
Asymmetric cryptography is about establishing that shared secret over an insecure network. RSA encryption, Diffie-Hellman... are algorithms which can help you with that. You still have to begin somewhere; i.e., if you use the public key of the server (its RSA public key, its half of Diffie-Hellman...) then you must have some way to know that you are using the right public key, not the public key of some bad guy who intercepts the communication and feeds you his own key instead. There are ways to do that, mainly with hardcoding a public key within the client application, public key which is either the server public key or a key which can be used to sign it (that's certification). Of course, with Silverlight the client code is also downloaded, hence potentially tweaked by the same bad guy, so you would have to sign the code and have the browser verify that signature.
All this is hard work and has scores of pitfalls. The SSL protocol went through all of them, and was patiently but painfully updated and fixed. It took many years and many smart people, and there was much grinding of teeth. A similar protocol is SSH (some encoding details differ but the principles are the same). If you want to design your own protocol, then chances are that you will reenact most of the weaknesses and issues that plagued SSL and SSH. Simply using SSL or SSH would save you much time and trouble.
You could use a public/private key encryption system like RSA. The client would encrypt a packet using the well-known public key of the server, send the encrypted data, and the server would decrypt it using the secret private key. Anyone can send the server data encrypted using the public key, but only the server can decrypt it. Just like SSL does.
Which brings us back to the question: why aren't you using SSL?
If you have a WPF control library which you wanted to license to developers, how do enforce license restrictions such that the library could be used and distributed in their own applications and yet prevent the end-users from reusing that .dll?
I'm approaching this from a strict business perspective, so I'm trying to find a solution that wouldn't allow indiscriminating users to do something as simple as pass the .dll around with the key and be able to share it.
Any thoughts on this are absolutely welcome and feel free to wax philosophical.
Strictly speaking, these kind of problems are really hard to solve completely, and whatever you do, it WILL be possible (though it might be hard enough) to alter the IL code that validates the license and bypass the check completely. However, if you're really comfortable with it, you could force your clients to submit the compiled version of their application to you to apply a strong name to it (using your private key). This way, you can check the public key token of the calling assembly against a specific key that only you own. By no means I suggest such a method for generic use, but if it's REALLY THAT NECESSARY to do so, this could work. Just keep in mind that it would probably take a few hours to find the license checking code in your assembly and removing it altogether. This will render any license restriction useless!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My company is looking to start distributing some software we developed and would like to be able to let people try the software out before buying. We'd also like to make sure it can't be copied and distributed to our customers' customers.
One model we've seen is tying a license to a MAC address so the software will only work on one machine.
What I'm wondering is, what's a good way to generate a license key with different information embedded in it such as license expiration date, MAC address, and different software restrictions?
I've used both FLEXlm from Macrovision (formerly Globetrotter) and the newer RLM from Reprise Software (as I understand, written by FlexLM's original authors). Both can key off either the MAC address or a physical dongle, can be either node-locked (tied to one machine only) or "floating" (any authorized machine on the network can get a license doled out by a central license server, up to a maximum number of simultaneously checked-out copies determined by how much they've paid for). There are a variety of flexible ways to set it up, including expiration dates, individual sub-licensed features, etc. Integration into an application is not very difficult. These are just the two I've used, I'm sure there are others that do the job just as well.
These programs are easily cracked, meaning that there are known exploits that let people either bypass the security of your application that uses them, either by cutting their own licenses to spoof the license server, or by merely patching your binary to bypass the license check (essentially replacing the subroutine call to their library with code that just says "return 'true'". It's more complicated than that, but that's what it mostly boils down to. You'll see cracked versions of your product posted to various Warez sites. It can be very frustrating and demoralizing, all the more so because they're often interested in cracking for cracking sake, and don't even have any use for your product or knowledge of what to do with it. (This is obvious if you have a sufficiently specialized program.)
Because of this, some people will say you should write your own, maybe even change the encryption scheme frequently. But I disagree. It's true that rolling your own means that known exploits against FLEXlm or RLM won't instantly work for your application. However, unless you are a total expert on this kind of security (which clearly you aren't or you wouldn't be asking the question), it's highly likely that in your inexperience you will end up writing a much less secure and more crackable scheme than the market leaders (weak as they may be).
The other reason not to roll your own is simply that it's an endless cat and mouse game. It's better for your customers and your sales to put minimal effort into license security and spend that time debugging or adding features. You need to come to grips with the licensing scheme as merely "keeping honest people honest", but not preventing determined cracking. Accept that the crackers wouldn't have paid for the software anyway.
Not everybody can take this kind of zen attitude. Some people can't sleep at night knowing that somebody somewhere is getting something for nothing. But try to learn to deal with it. You can't stop the pirates, but you can balance your time/effort/expense trying to stop all piracy versus making your product better for users. Remember, sometimes the most pirated applications are also the most popular and profitable. Good luck and sleep well.
I'd suggest you take the pieces of information you want in the key, and hash it with md5, and then just take the first X characters (where X is a key length you think is manageable).
Cryptographically, it's far from perfect, but this is the sort of area where you want to put in the minimum amount of effort which will stop a casual attacker - anything more quickly becomes a black hole.
Oh, I should also point out, you will want to provide the expiration date (and any other information you might want to read out yourself) in plain text (or slightly obfuscated) as part of the key as well if you go down this path - The md5 is just to stop the end user from changing he expiration date to extend the license.
The easiest thing would be a key file like this...
# License key for XYZZY
expiry-date=2009-01-01
other-info=blah
key=[md5 has of MAC address, expiry date, other-info]
We've used the following algorithm at my company for years without a single incident.
Decide the fields you want in the code. Bit-pack as much as possible. For example, dates could be "number of days since 2007," and then you can get away with 16-bits.
Add an extra "checksum" field. (You'll see why in a second.) The value of this field is a checksum of the packed bytes from the other fields. We use "first 32 bits from MD5."
Encrypt everything using TEA. For the key, use something that identifies the customer (e.g. company name + personal email address), that way if someone wants to post a key on the interweb they have to include their own contact info in plain text.
Convert hex to a string in some sensible way. You can do straight hex digits but some people like to pick a different set of 16 characters to make it less obvious. Also include dashes or something regularly so it's easier to read it over the phone.
To decrypt, convert hex to string and decrypt with TEA. But then there's this extra step: Compute your own checksum of the fields (ignoring the checksum field) and compare to the given checksum. This is the step that ensures no one tampered with the key.
The reason is that TEA mixes the bits completely, so if even one bit is changed, all other bits are equally likely to change during TEA decryption, therefore the checksum will not pass.
Is this hackable? Of course! Almost everything is, but this is tight enough and simple to implement.
If tying to contact information is not sufficient, then include a field for "Node ID" and lock it to MAC address or somesuch as you suggest.
Don't use MAC addresses. On some hardware we've tested - in particular some IBM Thinkpads - the MAC address can change on a restart. We didn't bother investigating why this was, but we learned quite early during our research not to rely on it.
Obligatory disclaimer & plug: the company I co-founded produces the OffByZero Cobalt licensing solution. So it probably won't surprise you to hear that I recommend outsourcing your licensing, & focusing on your core competencies.
Seriously, this stuff is quite tricky to get right, & the consequences of getting it wrong could be quite bad. If you're low-volume high-price a few pirated copies could seriously dent your revenue, & if you're high-volume low-price then there's incentive for warez d00dz to crack your software for fun & reputation.
One thing to bear in mind is that there is no such thing as truly crack-proof licensing; once someone has your byte-code on their hardware, you have given away the ability to completely control what they do with it.
What a good licensing system does is raise the bar sufficiently high that purchasing your software is a better option - especially with the rise in malware-infected pirated software. We recommend you take a number of measures towards securing your application:
get a good third-party licensing system
pepper your code with scope-contained checks (e.g. no one global variable like fIsLicensed, don't check the status of a feature near the code that implements the feature)
employ serious obfuscation in the case of .NET or Java code
The company I worked for actually used a usb dongle. This was handy because:
Our software was also installed on that USB Stick
The program would only run if it found the (unique) hardware key (any standard USB key has that, so you don't have to buy something special, any stick will do)
it was not restricted to a computer, but could be installed on another system if desired
I know most people don't like dongles, but in this case it was quite handy as it was actually used for a special purpose media player that we also delivered, the USB keys could thus be used as a demo on any pc, but also, and without any modifications, be used in the real application (ie the real players), once the client was satisfied
We keep it simple: store every license data to an XML (easy to read and manage), create a hash of the whole XML and then crypt it with a utility (also own and simple).
This is also far from perfect, but it can hold for some time.
Almost every commercial license system has been cracked, we have used many over the years all eventually get cracked, the general rule is write your own, change it every release, once your happy try to crack it yourself.
Nothing is really secure, ultimately look at the big players Microsoft etc, they go with the model honest people will pay and other will copy, don't put too much effort into it.
If you application is worth paying money for people will.
I've used a number of different products that do the license generation and have created my own solution but it comes down to what will give you the most flexibility now and down the road.
Topics that you should focus on for generating your own license keys are...
HEX formating, elliptic curve cryptography, and any of the algorithms for encryption such as AES/Rijndael, DES, Blowfish, etc. These are great for creating license keys.
Of course it isn't enough to have a key you also need to associate it to a product and program the application to lock down based on a key system you've created.
I have messed around with creating my own solution but in the end when it came down to making money with the software I had to cave and get a commercial solution that would save me time in generating keys and managing my product line...
My favorite so far has been License Vault from SpearmanTech but I've also tried FlexNet (costly), XHEO (way too much programming required), and SeriousBit Ellipter.
I chose the License Vault product in the end because I would get it for much cheaper than the others and it simply had more to offer me as we do most of our work in .NET 3.5.
It is difficult to provide a good answer without knowing anything about your product and customers. For enterprise software sold to technical people you can use a fairly complex licensing system and they'll figure it out. For consumer software sold to the barely computer-literate, you need a much simpler system.
In general, I've adopted the practice of making a very simple system that keeps the honest people honest. Anyone who really wants to steal your software will find a way around any DRM system.
In the past I've used Armadillo (now Software Passport) for C++ projects. I'm currently using XHEO for C# projects.
If your product requires the use of the internet, then you can generate a unique id for the machine and use that to check with a license web service.
If it does not, I think going with a commercial product is the way to go. Yes, they can be hacked, but for the person who is absolutely determined to hack it, it is unlikely they ever would have paid.
We have used: http://www.aspack.com/asprotect.aspx
We also use a function call in their sdk product that gives us a unique id for a machine.
Good company although clearly not native English speakers since their first product was called "AsPack".