I am writing a mac app. I want to know how to save a product key is a relatively safe and reasonable way.
For example, the way to restore Microsoft Office product key(I do not know it). Keychain maybe safe, but it is easy to find on mac.Which has a good solution?
NET supports public key encryption in various ways, such as http://msdn.microsoft.com/en-us/library/ms867080.aspx. Having said this, all you'd gain is some confidence that someone with full access to the released code would not have the ability to issue their own product keys. None of this stops them from patching the client to accept anything as a valid key. That's where obfuscation fits in.
From Encryption Product Keys : Public and Private key encryption
Related
I am integrating sparkle in my mac app for automatic updates of app. following this but i have problem with step 3 Segue for security concerns
EdDSA (ed25519) signatures
To prepare signing with EdDSA signatures:
First, run ./bin/generate_keys tool (from the Sparkle distribution root). This needs to be done only once. This tool will do two things: * It will generate a private key and save it in your login Keychain on your Mac. You don’t need to do anything with it, but don’t lose access to your Mac’s Keychain. If you lose it, you may not be able to issue any new updates! * It will print your public key to embed into applications. Copy that key (it’s a base64-encoded string). You can run ./bin/generate_keys again to see your public key at any time.
Add your public key to your app’s Info.plist as a SUPublicEDKey property.
I have few questions on this implementation
1.what if i lost in future the Private key which is stored in keychain
2.can we store this private anywhere else to be safe
What are the all best practices that i can follow to be safe. Any experts with detailed explanation would be appreciated.
I have tried to export the private but there is no option this is private key stored in key chain . these are the options that i am getting when trying to export.
Any Suggestions ?
Thanks in Advance !!
I am making a shared object that does a lots of encryption and decryption using public key and private key. I want store these keys within the binary, Is there any way to save these keys securely so that no one can use it . so How to embed a cryptographic key in a binary ?
If the code can access the keys, so can the users on whose machine the code is running. This is incontrovertible - there's no way around it unless you control the hardware.
Is there any way to save these keys securely so that no one can use it .
As millimoose said, no you can not. Or perhaps more accurately: you can not save data, any data, in a binary such that it is of use to your binary and not anyone else. While not usually discussed with this generic of a use case, this is the heart of Digital Rights Management - a desire to have some data (be it cryptographic or otherwise) that is only usable in a controlled manner.
The best you can accomplish, and this is a lot of work even for well funded and motivated organizations, would be to use the TPM to perform cryptographic operations on your behalf and in a manner that is tied to the state of the system. I'm guessing that solution isn't what you are looking for.
You cannot do this if you don't have control over the hardware and operating system. If you have full control, then then there is little need to add additional protection to the key. The best way of security storing keys is keeping them out of the binary. You could for instance use a secure token. This could be a TPM, a smart card or even a HSM. Those secure tokens do the cryptographic calculations on the token itself, so you never need to load it into memory.
If you want to have a very safe storage in a binary then you could take a look at this HSM. You can run your code within the HSM. Even with such a HSM, you should only generate the keys within the HSM and keep them in there. Oh, yeah, this requires you to spend several thousand dollars on an HSM...
We intend to sell our framework on the net ,and it needs to be protected in a matter than if someone buying it, he can't put it on the net, or give it to other developers .
We dont want to find it all over the net after a few months.
I had a few ways in mind but each had its catch .
Give a unique ID to every developer, and program that id to the framework, so he must enter that to use it. problem is ,that he can give the framework with the id to anyone .
Ask for the device number and enable only that device in my framework for each developer. problem here is that when he put it on store, all users cant use that since they have others device id.
Use the net to check some how(??) which i preferred not to limit the users to that need.
I can program each framework with a code, that only me can extract, so when i find it on the net i can be sure what dev put it in there (it doesn't help-i cant sue everyone)
Is there any other way to make the framework per developer but also let it work on all other users at the appstore when its there ?
Thanks .
#diederikh makes very good points, and NicolasMiari also provides good insight. The best answer IMO is a combination of these two. (While keeping in mind diederikh's excellent advice that your goal is to come up with something simple that will make things hard on legitimate customers.)
Rather than recompiling your entire framework for every customer, you make your license key depend on their bundle identifier. They send you their bundle ID. You use your private key and sign their bundle id. This provides you a hash that you send to them. Now, at runtime, your framework uses the public key (which is not sensitive; you could publish it anywhere) to verify your signature. See SecKeyRawVerify() for doing that on iOS.
You can use this approach to create time-limited keys. Just include time stamps in the signed data.
Using this approach, you could, if you wanted, let customers test your framework indefinitely by using your bundle identifier. You would make a signed hash of that identifier available to trial customers. But as soon as they want to upload to AppStore, they would have to change the identifier and pay you for a new signed key.
There certainly is a way to get around this. Attackers could modify your framework to ignore the signature verification. But that's always true, and preventing that is better done with lawyers after the fact than with DRM that will only likely cause trouble for paying customers.
Look at how PSPDFKit does it. If you want to use it out of demo mode you'll have to call a method with an unique ID. This ID will enable functionality which is not available in demo mode.
You can also sign (with the codesign tool) the framework with an unique certificate for each customer.
I would not worry too much; if will always find a way around your locks.
I need to hide a password to connect with a server. The problem is that the password is given by the service providers, so it is static.
I already thought of using the keychain, but the problem is that even if I use this I need to hard code the password to insert it in the keychain somewhere in the code.
So, is there a way to hide a static password to be available for my app, avoiding to write it in my code?
I would think about setting up a middle layer server - kind of a proxy - between users of your app and the service provider. It will allow you to:
set different password for each user
optionally give users a chance to change a password
have more control over who uses the service and what data is transmitted
be more independent of your service provider (e.g. change it anytime)
It will require more effort but may be it is more advantageous in long run.
This is not a solvable problem, and has been discussed at length around SO. For one "hub" question that includes links to several others, see Secure https encryption for iPhone app to webpage.
Using obscurity is not a horrible thing. But keep it simple. XOR the value with some random key. Done. Putting more and more layers buy you nothing, and cost you complexity (which means time and bugs, which are the enemies of both profit and security). If someone puts a debugger on your code, they're just going to log all the data you send to the server, so all the hoops you jump through to hide how you compute the password won't matter, because eventually you have to send it to the server. So keep it simple to stop people from just using "strings" to pull it out, and recognize that you cannot stop a debugger.
The only way to secure the service-provider's key is to put that key on your server, and then proxy for the service after authenticating the user. If you put it in the code, then it is discoverable, period. If this were a solvable problem, there would be no unlicensed copies of software, no unlicensed copies of music, no jailbreaks for iPhones, etc etc etc. If Apple can't stop reverse engineering when controlling every piece of the system from the hardware to the OS, you're not going to fix it inside of an app.
What you should be thinking about is how to recover if and when the key is lost. How do you discover that it's happened? How do you expire that key and create a new one? If you're shipping the key in the code, you must assume that it eventually will be discovered, and you should have a plan for dealing with it.
As a side note, one technique I've used in the past is to download the key from our server on-demand rather than encoding it anywhere in the app. We use authenticated HTTPS and check our certificates. Of course it is still possible to fool this system (it's always possible to fool a system that gives a client information they're only supposed to use a certain way), but the thinking is at least we can change the key more easily this way to stem the tide briefly if the key leaks.
This is the key and the box problem, you can keep putting your key in a new box every time and hide this key in a new box and you can keep on doing this.... but in the end you always have the last key... and nowhere to hide it.
Personally i would obfuscate the key to the keychain, and hide the real key in the keychain.
If it is a realy important secret you can use AES to encrypt your key, but then again your stuck with your encryption key, here you can use something that is device specific instead of a hardcoded value and generate your key out of that property.
For sure not perfect but will do the job in most cases.
I have a client who is interested in adding in electronic signature support to a long (40 question) seller application form. I'm a little stumped on whether there is an existing standard or process that's out there that folks in the financial world would expect to see?
I could certainly add in a system where we generate a bunch of text based on their responses, have the applicant sign it with their private key and upload a public key- but that seems like a lot to ask of people. Do non-nerds even have PGP installed these days?
Is there a standard approach to this out there? Anyone work in the financial world that's done this and had it work well?
We use Alphatrust's e-Sign Software.
What purpose is the signature trying to fill? Are you trying to verify that the form actually came from a specific seller? (If so, you would have to know their public key ahead of time.) Are you trying to hold the seller accountable for their answers at a later date? (In that case, you might need some kind of third-party involved.)
Sometimes people ask for electronic signatures just because they sound neat.
If these forms are meant to be shared throught to a general public you'll need to know (and can validate, that's the hardest part) all the producers of these amount of certificates people could use to sign these forms, and it's almost impossible.
With closed environments (like functionaries, doctors...) where all the users are suposed to hold a certificate (with a pre-known CA you trust) and you should be sure the form is sended by someone trusted (non repudation, integrity...) it's a better scenario to sign a form, otherwise I do not recomend you to use signed forms to achieve your goal.