I have proprietary information (formulas etc) stored in a property list which is shipped with the app.
The property list will be created and edited by the property list editor in Xcode.
How can this property list be encrypted in iOS 5 to avoid reading the property list formulas by the user? I am looking for a solution that is very transparent and easy to implement.
First, this is a very specific form of the question "how do I prevent my application from being reverse engineered." The answer is you don't. You can implement some basic things to try to hide the information from an attacker. But there is no way to give your code to an attacker who has complete control of the hardware it runs on and still prevent it from being reverse engineered. For general discussion about this, see Obfuscating Cocoa. More versions of this question are listed in Secure https encryption for iPhone app to webpage.
So the real question is how to hide your information from the casual attacker, realizing that the dedicated attacker will defeat your scheme. When you ask the question that way, you realize that part of the answer is "as easily as possible because it would be silly to spend a lot of effort doing it if it's not going to be highly successful."
So shuffle the file with a long, random shared secret. Stick the shared secret in your code, and press on with life. If you want a good tool, I recommend CommonCrypto since it's built-in. Just remember that this is just obfuscation. As long as the key is in the software, you can't consider it "encryption."
If your secrets are valuable enough that you you have significant ongoing technical and legal resources to protect them, then mail me some more details and we can talk about how you create an anti-piracy and trade-secret protection team within your organization (I have experience doing that and would be happy to provide consultation expertise). But remember, Apple controls the iPhone top to bottom and has spent serious money to secure it. It's still jailbroken. Unless you are going to apply resources on a similar scale, you shouldn't expect a better result. In almost all cases, you are better off spending your resources making your product better than in protecting what you've shipped.
Examples are in the iOS Developer Library.
https://developer.apple.com/library/ios/#documentation/Security/Conceptual/CertKeyTrustProgGuide/iPhone_Tasks/iPhone_Tasks.html#//apple_ref/doc/uid/TP40001358-CH208
Related
I recently read about decompilation of iOS apps and I'm now really concerned about it. As stated in the following posts (#1 and #2) it is possible to decompile an iOS which is distributed to the App Store. This can be done with jailbreak and I think with copying the app from memory to hdd. With some tools it is possible to
read out strings (strings tools)
dump the header files
reverse engineer to assembly code
It seems NOT to be possible to reverse engineer to Cocoa code.
As security is a feature of the software I create, I want to prevent bad users from reconstructing my security functions (encryption with key or log in to websites). So I came up with the following questions:
Can someone reconstruct my saving and encryption or login methods with assembly? I mean can he understand what exactly is going on (what is saved to which path at which time, which key is used etc., with what credentials is a login to which website performed)? I have no assembly understanding it looks like the matrix for me...
How can I securly use NSStrings which cannot be read out with strings or read in assembly? I know one can do obfuscation of strings - but this is still not secure, isn't it?
This is a problem that people have been chasing for years, and any sufficiently-motivated person with skills will be able to find ways to find out whatever information you don't want them to find out, if that information is ever stored on a device.
Without jailbreaking, it's possible to disassemble apps by using the purchased or downloaded binary. This is static inspection and is facilitated with standard disassembly tools. Although you need to have a tool which is good enough to add symbols from the linker and understand method calls sufficiently to be able to tease out what's going on. If you want to get a feel for how this works, check out hopper, it's a really good disassembly/reverse-engineering tool.
Specifically to your secure log in question, you have a bigger problem if you have a motivated attacker: system-based man-in-the-middle attacks. In this case, the attacker can shim out the networking code used by your system and see anything which is sent via standard networking. Therefore, you can't depend on being able to send any form of unencrypted data into a "secure" pipe at the OS or library level and expect it not to be seen. At a minimum you'll need to encrypt before getting the data into the pipe (i.e. you can't depend on sending any plain text to standard SSL libraries). You can compile your own set of SSL libraries and link them directly in to your App, which means you don't get any system performance and security enhancements over time, but you can manually upgrade your SSL libraries as necessary. You could also create your own encryption, but that's fraught with potential issues, since motivated hackers might find it easier to attack your wire protocol at that point (publicly-tested protocols like SSL are usually more secure than what you can throw together yourself, unless you are a particularly gifted developer with years of security/encryption experience).
However, all of this assumes that your attacker is sufficiently motivated. If you remove the low-hanging fruit, you may be able to prevent a casual hacker from making a simple attempt at figuring out your system. Some things to avoid:
storing plain-text encryption keys for either side of the encryption
storing keys in specifically named resources (a file named serverkey.text or a key stored in a plist with a name which contains key are both classics)
avoid simple passwords wherever possible
But, most important is creating systems where the keys (if any) stored in the application themselves are useless without information the user has to enter themselves (directly, or indirectly through systems such as OAUTH). The server should not trust the client for any important operation without having had some interaction with a user who can be trusted.
Apple's Keychain provides a good place to store authentication tokens, such as the ones retrieved during an OAUTH sequence. The API is a bit hard to work with, but the system is solid.
In the end, the problem is that no matter what you do, you're just upping the ante on the amount of work that it takes to defeat your measures. The attacker gets to control all of the important parts of the equation, so they will eventually defeat anything on the device. You are going to need to decide how much effort to put into securing the client, vs securing the server and monitoring for abuse. Since the attacker holds all of the cards on the device, your better approach is going to be methods that can be implemented on the server to enhance your goals.
On OSX a user can delete NSUserDefaults either using the defaults utility or deleting the plist. See man defaults. Is there a way this can be monitored, considering the app would like to catch and take appropriate actions if the user or any malicious program does this. Deleting either way does not invoke NSUserDefaultsDidChangeNotification at all and hence cannot be used.
If you need to secure settings, use the keychain. If you want to do so without incurring the pain and suffering of learning the keychain, there are several wrappers available that make string entries look like User Defaults.
There are two different things here: "if the user or any malicious program does this."
Regarding "if the user..." the answer is no. The user can do anything she wants. She can modify your program if she wants. It's her hardware. In order to prevent that, you have to develop effective DRM. You're not going to do that on top of NSUserDefaults. Apple can barely pull that off when they control every piece of the ecosystem. Basically, if you could solve this problem, Apple could use the same solution to prevent jailbreaks of iPhones.
If the idea is that you just want to obfuscate things a bit from the user, and aren't trying to deal with a motivated and skilled attacker, then NSUserDefaults is not the right tool. It has "user" right in the name. It's the user's stuff. Put your secret things in a hidden place. You'll have to come up with your own idea for that, since the only reason it would work at all is because it's a secret only you know. (This will be broken very quickly by a motivated attacker of course, but it will work for most of the users who any other system would work for; keep it simple.)
Regarding "any malicious program," that's a bit different, since you're protecting your user (a tractable problem) rather than trying to protect yourself from your user (an intractable problem). Storage in keychain would probably be a good choice. It has several built-in protections from malicious applications accessing it. You can also store your data on a server rather than on the box, which would protect against most malicious software (particularly assuming you sign your app, so malicious software can't modify it).
If what you're really trying to do is manage trials and licensing, there are several products on the market to help you obfuscate your keys, trial periods, etc. They spend their money developing and refining obfuscation and adapting as attackers break it. It's a full-time job. Unless you have a team to devote to it, I'd use one of the commercial products. It won't really fix your problem (those products are cracked all the time), but at least you can get back to real development.
If it's not sensitive then save it using NSUserDefaults. It it is sensitive the use the keychain. If you want to store information securely using NSUserDefaults (AES-356 bit encryption) then look into SecureNSUserDefaults(I have colleagues that use this but I haven't had a need to myself).
Otherwise, save your data (encrypted by your own means if you wish) using your own preferred data structure (dictionary or the like) to your app's documents folder.
Ultimately, anything that you store client side can be removed by the user. But you can try to stop it being deciphered and/or edited.
I'm creating a windows form app and the underlying code needs to be secure. In the code is database information and many equations which people should not be able to see.
What I'm asking is if I install the app on someone's computer, how easy is it for them to "break" into the application and view this sensitive information? If it's not difficult for them to find the code, are there ways to prevent this from happening? I would appreciate any input.
It's very easy to view code. Tools like ILSpy or .NET Reflector can practically show your code as you have written it in C# or VB.NET.
There are some possibilities, some free or cheap, some will cost you:
Obfuscation: This replaces names and sometimes logic in your excutable with other code that is hardly human readable. This is easy to do and there are tools like Confuser that do a good job, but the code is still there and can be read. It's only slowing attackers down.
Another option that I have evaluated myself is using hardware protection in the form of Dongles. Here the whole application is encrypted with a secret key that is stored on a smartcard. Portions of the code that are needed are decrypted on the fly at runtime and executed. Since the code is encrypted you can't read it easily. Solutions like Codemeter are pretty hard to beat (there are no real cracks for these if implemented correctly, which isn't hard. But this is not for free.
You always need to have the scope of your protection in mind. Who do you want to keep from getting your code?
The average guy who also has used .NET some times and knows how to google and download ILSpy? Obfuscate it mildly and he will be annoyed enough to leave it be.
Some other people who really know what they are doing but still without financial interest? Use some more drastic obfuscation like code restructuring and so on and they will probably not invest weeks of their time to just finding some formulas.
Some other company who is willing to put in the financial ressources and the knowhow of talented people to get your code to make a profit? Obfuscation will not help you. Maybe encryption will, maybe not.
We went with the Dongle solution since we also want to manage licensing in an easy way for the customers (of which most have very restricted online capabilities), while the code protection is a very nice additional feature.
You can use two-way cryptography before storing the information on the database. This question's answer has an explanation of how to do that very simply: Simple insecure two-way "obfuscation" for C#
About the equations, if they're hardcode in your app, and you don't deliver the source code of the app, the only way to retrieve it is using disassembly, wich, even with very simple tools, you have to be "computer savy" to do it.
I work on a project known as the Security Development Lifecycle (SDL) project at Microsoft (http://microsoft.com/sdl) - in short it's a set of practices that must be used by product groups before they ship products to help improve security.
Over the last couple of years, we have published a great deal of SDL documentation, as customers ask for more information about what we're doing.
But what I'd like to know is:
What are you doing within your organization to help improve the security of your product?
What works? What doesn't work?
How did you get management to agree to this work?
Thanks.
Honestly, Reading your book was a good start. :-)
Responding to your questions:
Crypto is a hobby of mine that I sometimes blog about (e.g. on TLS and AES). After writing my own implementation of AES, I learned enough to know beyond a reasonable doubt that I should never use my own implementation but rather use the ones written by the CryptoAPI and OpenSSL guys.
Code reviews where people that are good at security issues are marked as required.
Having a class on-site with labs to raise awareness of issues mentioned in your book as well internal mailing lists discussing new issues.
Several folks listen to the Security Now podcast to keep current on what types of issues are out there and what is getting attacked. This indirectly affects design.
Except for an on-site course and buying the code review tool, none of these require management approval.
I'm an indie mac developer, but also a platform security evangelist: I'm the author of Pro Cocoa Application Security published by Wrox. In that book I champion the secure dev technique I use myself: it's based on the Swiderski and Snyder threat modeling, but with two changes. I make it lighter weight by considering which entry points access which assets without using DFDs. I also put more focus on identifying users and misusers, which I think makes it more applicable to shrinkwrap software.
As far as tool support is concerned, I use the Xcode static analyzer (based on clang), but have found it doesn't detect some common vulnerabilities. I did file bugs though :-). I also always use the gcc _FORTIFY_SOURCE macro. There aren't good Mac risk analysis tools but I'm working on that... ;-)
I've spoken on security to Mac devs at conferences and in podcasts and gotten plenty of feedback, if you want me to clarify anything I've said or are interested in the community feedback please ask in comments. Private questions are welcome to (though I'd prefer to stay on the forum): iamleeg at securemacprogramming dot
com.
We think before we code. Strangely enough, it avoids many bugs, including those which are exploitable by adverse parties and henceforth known as "security holes".
Part of the trick is not letting anyone near a keyboard unless he has a solid amount of experience and expertise.
I've a question about a good way to protect a bit my cocoa app from piracy. I know that this is impossible!
So, in my app I've an isRegistered() method that runs every time the user launch the app.
This is called from the applicationDidFinishLaunching: App delegate. So if this method returns true, the app continues to execute the code, otherwise an Alert appears saying that the app is not registered and there are xx day to buy a license.
This is a good way? Because, I have no experience in this.
Thank you in advance for your help!
SOLVED
First of all, thanks to everybody! I think the same thing: any copy protection can stop the piracy. I'm trying only to solve this little bug, even if I know that someone will crack my app again.
However, it's true - the best thing is to improve the app and not waste the time to try make the piracy protection more efficient.
The solution you describe requires almost no expertise whatsoever to crack. It is trivial to change your isRegistered() function to always return true. Thus, the effort required to circumvent your protection is a tiny fraction of the effort you would have to spend implementinging all the infrastructure to support users purchasing registration codes.
In other words, you're not getting a good return on investment. There is some debate over whether the return on investment implementing piracy protection (rather than improving your product) is ever good enough (because you pit yourself against people who have nothing better to do than prove they're cleverer than you).
One good way to redress the balance of return on investment is to use pre-existing code such as AquaticPrime. That way, at least you won't have spent so much time chasing rainbows :)
I am not in shrink-wrapped software business but my friend is. And his observation after 10 years of selling his product was that it makes no sense to create too sophisticated protection because always some one will hack it. You are alone and world is infinite. It is better to invest time/money in improving your software than working on copy protection.
Also keep in mind that around 10% of will never steal and other 10% will always try. Just make sure that those 80% is able to buy your product without any other mayor obstacle. Than you could ignore those nasty 10%. Actually it is a quote from Joel Spolsky IHMO.
So your solution seems to be completely OK from technical point of view and just stay with it.
it's almost never worth implementing your own anti-piracy system, because you'll almost always spend a lot of effort on something which can then be broken very easily. Rely on a shared implementation - in this case a framework like AquaticPrime (lots of people on the macsb mailing list recommend that one) - and you're effectively relying on the framework being good enough to protect your own app as well as all the others.
The code signing framework on Leopard and later allows you to sign your code such that if it's ever tampered with, it will refuse to run - see the documentation of the kill option in the manpage.
This is a good question. Having read the answers, I think what BitDrink was really getting at was this: we know that an isRegistered() function is dead simple to hack. With the understanding that any protection system eventually will be hacked, what are some strategies for writing a function that's harder to hack than an isRegistered function that returns a boolean?
Fundamentally, any copy protection system will eventually have something that looks like this:
if (program is registered)
let the program continue
else
nagging message
end
Any hacker with a copy of GDB will eventually find that first line and write a tiny little patch to strip it out. Most copy protection systems focus on security through obscurity, i.e. making that line hard to find. You can also make this system more robust by signing the binary and checking the signature, but you'll just add another hoop for the hackers to jump through. They'll eventually find your public key and change it to their own public key so they can replace your signature. However, I believe this will significantly slow them down. Leopard offers a code signing utility, but I don't know if it can be used to prevent incorrectly signed applications from running at all.
There's no perfect solution to this problem, but there are two main things to remember:
your registration system will be broken. There is absolutely no way around this.
your reigstration system is a barrier between the user and your program. You should optimize for the (hopefully majority of) legitimate users and make this as easy to do as possible.