I am building a distributed application in which the software is installed by my company on our customer's hardware. The customer can therefore tamper with the software. I would like to know if a technique exists so that when the software running on customer hardware make a web request to our central server (i.e. totally under our control), that we can validate that the request is coming from an untampered version of our software.
I believe that this is referred to as "remote attestation." Web searches about remote attestation return a variety of results, from "it is not possible" to "use the TPM". But I have not been able to find a simple to understand example of how to code this in Windows.
So, my question is: Is remote attestation possible in Windows, and if so, is there a working example that I can use as the basis for implementation?
Note: Remote attestation is sometimes achieved through "obscuration" techniques such as embedding a "shared secret" into the application and then obscuring it in various ways to try and ensure that an attacker cannot easily extract that shared secret through de-compiling etc. I am not interested in such techniques and am looking for something that provides real security not security through obscurity.
In order to attestate a system you need 2 things:
A chain of trust from a root of trust up to every executed code and
Means to interpret and verify the obtained measurements on your server.
When using Windows you have neither.
Currently not even Windows itself is aware of its sate. However, that improved in Windows 8. Now you have measurements of the boot loader and drivers at least. But nothing that extends to user code.
Related
Assume the following scenario: we want to implement an open-source password manager that uses a central service that enables the different clients (on different devices) to synchronize their local databases. It doesn't matter if this service is run by a company or on a server of the user (compare to owncloud usage scenarios). To make our application more "secure", we want to use an Intel SGX enclave for the central service (please ignore current attack research on SGX enclaves).
Then, the typical workflow would be:
local client attests central enclave
user registers / logs in
(local and remote database are synced)
user stores / retrieves passwords
Now my question: Does every user of our password manager need to register with the Intel Attestation Service (IAS)? If yes, wouldn't this imply that, since private key sharing is really bad, every single device needs to be registered?
According to my investigations, the answer is, at least for the development and testing phase, yes. I could not find any public information for production scenarios. All I know is that a business registration changes the behavior of the enclave (it can be run in production mode) which is not of any matter here. I have two thoughts on this:
If I am correct, isn't this another show stopper for SGX? Using SGX without the attestation feature seems to be useless.
How do services such as https://www.fortanix.com/ circumvent or solve the problem? Their documentation does not give a hint for needed interaction with Intel.
The above described scenario is only an example; it can be improved and we do not plan to implement it. But it was a lot easier to describe a scenario, that can be easy imagined and seems to be a realistic use case for SGX, than describing our current project plans.
P.S.: This question is kind of consecutive to Intel SGX developer licensing and open-source software
One does not need an Intel-registered certificate to create a quote but one does need to communicate with the IAS (Intel Attestation Service) to verify a quote, which requires an Intel-registered certificate. So every node checking if a remote attestation is valid would require such a certificate in a naive approach.
One could of course leverage SGX to provide a proxy which would be structured somewhat like that:
Generate two certificates and their corresponding private key, I'll name one of them the IAS-conn-cert and the other one the Proxy-cert.
Register the IAS-conn-cert of them to the IAS.
Of course, you need to have to trust that these certificates were indeed generated in an enclave. To do so, you could remotely attest to another service provider you trust.
Now pin (by for example hard-coding) the Proxy-cert in your client application. When it needs to verify a quote, it connects to the enclave using that pinned proxy-cert thus knowing it connects to the enclave. The enclave will then connect to the IAS and relay everything it receives from the client to the IAS and vise-versa. The client can now communicate with the IAS without having to own an IAS-registered certificate but can still be assured that there is no tampering in the proxy, given that it trusts that the proxy-certificate was indeed generated in a non-malicious enclave.
We (ISV) are currently planning to offer our software on a rental/subscription basis as a service.
It's a native Windows (C++ / .NET) B2B application.
Our software needs access to the file system (drives) on the customers computer and it also needs access to the network (e.g. be able to find other computers in the network).
We want to offer our customers a service where they do not have to bother themselves with setup/updates and always work with the newest version of our software. So we need a single point of maintenance.
In the first phase we do not expect a lot of our customers (let's say 20) to change to this model, so it would not be a problem to have to set them up and manage them manually, but in the long run a solution that allows an automated set/sign up process would be required.
What I found most promising was Citrix XenDesktop/XenApp with VM hosted Apps and personal vDisks, but it seems that the Citrix solution is not able to get access to the network on the client PC (I tried it with the trial in the Azure Marketplace). Also it seems to be high priced.
What would be other possible ways to meet these requirements?
Unless you can make some significant architectural changes to eliminate the need to access the local filesystem and and eliminate the need to do local network browsing, I would recommend focusing on optimizing your local installation and update process. And skip the virtualization/service idea "for now".
You can still go to subscription model with a locally installed application. Just require your application to "phone home" to check its licensing/subscription status on startup.
As part of an on-going project of mine, my task is to identify instructions in a code which are vulnerable to tampering.
The code would be running on an IoT device. And the identification of instructions can be from either the source code or just the executable(with no source code).
Does anyone know about some tools or techniques?
In a nutshell, how to automatically locate security-sensitive code?
EDIT: I believe now I have come to understand my task better. I do not have to use a tool to protect but devise a technique of my own to protect my code statements( written in C Language) which are vulnerable. Especially Anti-debugging statements.
Are there any heuristics to find out the vulnerable statements in the code. like authentication points and Anti-Debugging checks?
The fact that the software runs on a device is not different than software running on a web server or local/cloud computer.
What you might want to do is look at all the individual components in your setup that might expose a vulnerability.
The image below is a representation that I often use for describing a connected product from the highest level.
It contains:
The device (often running C or C++ code)
The connection to the cloud (like, https or a messaging service)
The API to the cloud (often a RESTful API)
The software on the cloud itself
You can go through these ones by one and identify what might be wrong. As a rule of thumb, you can always try to find the spot where an outside connection is made.
Following those four steps
Check if the code can be tempered with before an outside connection is made. If your code is compiled and makes an outside connection, try to find an alternative that you can validate.
Check certificates, messaging protocols etc. Makes sure all connections are following safety standards.
Make sure your API follows proper RESTful security measures.
Validate the software in the cloud, check certificates and use something like OATH.
Last, check services like https://www.checkmarx.com/
Setup
I have a SQLite database which has confidential user information.
This database may be replicated on other machines
I trust the user, but not other applications
The user has occasional access to a global server
Security Goals
Any program other than the authorized one (mine) cannot access the SQLite database.
Breaking the security on one machine will NOT break the security on other machines
The system must be updatable (meaning that if some algorithm such as a specific key generation algorithm is shown to be flawed, it can be changed)
Proposed Design
Use an encrypted SQLite database storing the key within OS secure storage.
Problems
Any windows hack will allow the person to access the key for all machines which violates goal #2
Notes
Similar to this method, if I store the key in the executable, breaking the security will comprimise all systems.
Also, I have referenced windows secure storage. While, I will go to an os specific solution if I have to, I would prefer a non-os specific solution
Any idea on how to meet the design goals?
I think you will need to use TPM hardware e.g. via TBS or something similar, to actually make a secure version of this. My understanding is, TPM lets the application check that it is not being debugged or traced at a software level, and the operating system should prevent any other application pretending to the TPM module that it is your application. I may be wrong though.
You can use some kind of security-through-obscurity kludge, but it will be crackable with a debugger unless you use TPM.
this is my first question so please be gentle...
I am working on a software which I would like to protect using some kind of licensing scheme.
A basic scheme would be to generate some "unique" key for a user. The user sends this key and a registration code when he wants to register the software and receives an activation code.
When the application runs it validates the activation code by comparing the "unique" key and a datablob received by decrypting the activation code.
This is fair and quite simple to implement, one can choose different crypto algorithms etc. however this scheme lacks two properties:
If the user manages to spoof hardware signature etc. to produce the same "unique" key on another computer he could use the same license data.
If the user decides to uninstall the application and wants to move it to another computer, there is nothing that prevents him from using the old license data again at the old computer and still obtaining new license data for the new installation.
Do you have any suggestions on how to resolve these issues?
One idea I had was to add some random data to the "unique" key, this random data would be stored in an obscure way, if the user deinstalls the application this random data would be removed, and some kind of hash with the previous random data and the license data would be generated which could be sent to me to verify that he really have uninstalled the application and made me sure that he wont be able to use the previous license data again since the random data had changed.
Over and out, for now...
EDIT:
I currently have a scheme that works, I should mention that the most common product is installed in an embedded enviroment where hardware-changes are very rare and if there is a hardware failure then most certain the machine is broken. But I could modify the hardware-key scheme to take into account and allow for some changes.
Also because of this the software will most likely not be run inside a VM, good point though and I haven't thought about that.
The application does not call out regularly, if a network connection is available the user gets the option to make a more automatic registration, otherwise he/she gets a registration key, enters it in the software and gets an installation ID which is provided to me, registration code + installation ID generates an activation key that the user gets from me which then unlocks the software.
What I am looking for is good/feasible solutions to the 2 points. Hardware spoofing, Revoking license keys i.e. to be sure the user can not use the same regcode+activationcode.
Thank you for all your feedback
It is not necessary to
First, you should make it clear what you're trying to protect. Apparently, you want to ensure that for each purchase of your application, there will only ever be one computer on which the application is installed and runnable.
You propose to use a hardware signature as part of each user's unique key. What happens if my hardware fails (e.g. my hard disk breaks)? I'm certainly not going to purchase your application if I can't go on using it after a hardware problem, so at a minimum you must be prepared to handle key change requests. You'd better respond fast, because if your application is important I want to minimize downtime. And I'm not inviting you to check that my hardware has failed, so you'll have to take my word for it. That means any user can get a free licenses from time to time by pretexting a hardware failure.
What about virtual machines? It's probably feasible to detect all currently existing virtual machine configuration, at the risk of a few false positives now and then. If you forbid virtual machines, how do you justify this to users? If you allow virtual machines, how do you prevent the user from making multiple copies of the whole VM? (This can happen even with physical machines, with hibernation).
Is the application going to call back to you every time it starts? I guess so, from your deinstallation scheme. That's a bandwidth and availabilty cost, and will also put off some users — not everyone is online, especially in sensitive environments. But then you don't need such a complex scheme: your server can keep track of how many copies of the application are running, though you do have to handle the case when the application doesn't terminate cleanly for any reason (application crash, OS crash, power failure, loss of connectivity...).
You don't discuss this in your question, but you have to protect the application executable, so that someone can't bypass the license check with a debugger.
Place your software into appliance hardware and put a padlock on the hardware. Ship the appliance to the customer.
If you believe the customer will hacksaw the appliance open to get your code, consider encrypting the storage medium.... Then they have to hacksaw the box AND find the keys. A TPM chip or secure USB token may aid with the latter.
Being a shareware author and longtime member of ASP myself i think you are going into the wrong direction with your solution. The only way to make this workable is with a hardware device as already suggested. This or constant online activations is the only way if you want to be sure and your product is so good and without competitors that your customers will still use it.
But what we (organized small ISV's) learned from practice is that you should not do what you are trying to do. Do not bind it to hardware. Sell one license per person not one license per computer. In the end you will make more sales because of the relaxed license.
Just do enough to make the honest people stay honest. So limit the trail version (i decided to terminate the application after one hour for me) and leave the final version free from all stuff. Give a separate download for payed customers and thats it. Be a nice company and not a greedy profit maximizing by legal restrictions company.
I used some of the better windows protection programs first but they all had serious problems with my code. And they call get cracked sooner or later. So i gave up all of them.
P.S.: I use a hardware fingerprint schema on windows where i don't restrict the program but just to keep people away from getting new trial keys every 30 days. Together with a nag screen it seems to work. The fingerprint is an xor of user name, windows installation time, modify time stamp of a system files and harddisk serial id.
Let the registration code also be the activation code.
You generate the unique registration code at point of sale, or packaged with the product. Customer registers/activates/deactivates with you (or your server) in one step using that single code. The customer's hardware doesn't have to generate any keys.
Reregistering/reactivating still requires contact with you, so you're aware of reinstall attempts.
I think that the only solution to your problem is a cryptographic hardware dongle. Usually it would be a USB-based tamper-resistant challenge-response dongle, that can be easily transferred between computers.
These devices cost less than $1 for large quantities, and not more than $10 for very small quantities. The good ones are very hard to forge, very easy to embed in your application, and usually supplied with a free EXE encryptor which also contains anti-debugging and anti-reverse-engineering functionality.