Hello i'm about to write an app that enables me to store remote files on iPhone's local disk to make the data permanent in a file and manipulate with it. But i have a question about this. I have no idea about encrypting data by the way.
So if any iPhone hacker crack the prone with jailbreak and access my local file? In this situation, i want to use Encryption. But i'm missing something. My json files contains long plain texts like 100,000 words. So if i apply the CryptoSwift library which is on Github now, using the AES and NSDATA my computer is stuck to encrypt it.
let plain = "mylongtextfromfile".dataUsingEncoding(NSUTF8StringEncoding)
let key: Array<UInt8> = [0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00]
let iv: Array<UInt8> = AES.randomIV(AES.blockSize)
let encrypted: NSData = try! plain!.encrypt(ChaCha20(key: key, iv: iv)!)
print(encrypted)
let decrypted: NSData = try! encrypted.decrypt(ChaCha20(key: key, iv: iv)!)
let string1 = NSString(data: decrypted, encoding: NSUTF8StringEncoding)
print(string1)
I also noticed that Apple does not want to use of another encryption libraries unlike its built-in APIs. The Itunnes connect policy requires an extended verification process of the app.
I want to ask you experts that what i must to do. I do not want to user to interact with any mobile service-back-end, API or server for downloading the words and query them once the users want to use the words each time.
What i need to use to keep the process fast. Actually is there any way to only encrypt file itself unless the data in. Or what is the mistakes i'm facing.
sincelery,
So if any iPhone hacker crack the prone with jailbreak and access my local file?
Yes. This is true, and there is nothing effective you can do about. You can create some layers of obfuscation. You can slow down attackers by a few hours. With sufficient resources and an ongoing team of security experts you may be able to slow down an attacker for longer. But if Apple with control of every piece of the ecosystem, and extensive and expert resources dedicated to it, can't stop attackers from jailbreaking the phone, you have no hope, especially, if as you say, you know nothing about encryption.
That is not to say that there is nothing at all you can do; it just won't be very effective, so don't spend tons of time on it. You must assume that if your data is of any significant value, attackers will extract it. You must design your system and business model to be resilient to that. Or you must employ an ongoing team to mitigate attacks, like Apple or Blizzard do.
So what can you do that will be simple and provide some kind of obfuscation, even if it's pretty ineffective? As you appear to be trying to do, encrypt it against a hard-coded key. It won't stop anyone who knows what they're doing, but it'll keep away some people, and that's about as good as you can do.
CryptoSwift is a nice library, written by a smart guy, but it's very low level, and assumes you know what you're doing. This is not the kind of tool you want to be using for this. You want something that does all the work for you. I have one, RNCryptor. It has the advantage of being very simple, cross-platform, and only using Apple crypto primitives. There is also libSodium which is even more portable and is a more powerful format, but doesn't use Apple's primitives.
The important thing to look for is something that offers an encryption format, not just crypto primitives. It is very challenging to build a secure format out of primitives. Don't attempt it without first studying how it's done.
If you do want to move forward with CryptoSwift, then you'll need to explain more precisely what is going wrong. When you say "my computer is stuck," what precisely is happening?
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 am trying to encrypt an NSString to both NSString and NSData in Objective-C and so I began a search.
I started off here, but that went way over my head, unfortunately.
I then found myself at this post and it came across to be very easy to follow, so I went along and tried to figure out the implementation. After looking over the implementation, I saw the second answer in the post and saw he had more adaptable implementations, which brought me to his gist. As per the gist readme, he "took down this Gist due to concerns about the security of the encryption/decryption". That leads me to believe that the security of the implementation from above has security flaws as well.
From that gist, however, he mentioned another alternative that I could use for encryption. After taking a look at the code, I noticed that it generates NSData with "a header, encryption salt, HMAC salt, IV, ciphertext, and HMAC". I know how to handle that to decode using the same library again, but how would I pass this off to a server guy, given that I don't quite know what I'm sending to him?
At the root of it all, I'm in over my head. Given what I said above and knowing that I don't have the time to take on a lot of learning for this, unless if it is absolutely necessary, how should I best handle going about this encoding/decoding process, given a private key with the end goal of shipping it off to a server that is not designed by me? (How's that for a run on sentence!)
Maybe you should ask the server guy? When ever you have encryption between too parties you have to have some kind of agreement on the format of that data, the raw primitives don't handle that alone, not to mention it's easy to mess things up security wise dealing with just the primitives and the desire to just send the aes ciphertext alone is going to cause mistakes.
RNCryptor, which you mention, is a high level encryption library it defines a simple format that others would have to conform too, it's simple thus helps going cross platform, but it has that extra that you need to do AES properly. There are other libraries like that too (NaCL, GPGME, and Keyczar), that are not as simple in format, but simple in usage, so you'd need to be able to use the library on both ends, but I'd highly recommend that you uses something like that, if you can, rather than rolling your own.
Keyczar specifically exists for java, python, c++, c# and go, so if you can use the c++ version on the iOS (or Mac, which ever you are targeting on the client) you might be good on the server as there are several choices.
I have developed an app for iPhone which communicates with a web server though XML based communication model.
In one of my source files, NetworkLayer, I created XML objects and send them to the web server. I have also declared all constants used in my app and also URLs (used to access my web server) in MyApp_Prefix.pch.
I want to ask if there is any way that some hacker can get access to my source code of generating XML objects or MyApp_Prefix.pch file if he has .app file of my app? Can anyone please help me in this regard?
No, he can't get your source code. But he can look at the HTTP requests and responses to see what XML you have created and what the server has sent back. Does that matter?
A hacker could reverse-engineer your code with some effort by looking at what your code tells the device to do. With some effort and knowledge of assembly and reverse engineering, one can see much of what your code contains. This does however require some serious effort and lots of time, so for most apps, it is unlikely that anyone would attempt to do so.
A much easier way would be to intercept the data on it's way to or from the server, and unless you are obfuscating the data, encrypting it or using SSL, you can't prevent this.
If you are worried about protecting your data, you should try some simple obfuscation. There are many ways to do this, the most popular one being XOR:ing your data with a key both the client and the server knows. Applying the key will flip the bits in your data and quickly and easily turn it into unreadable gibberish. Applying the same key again will flip the same bits again and you have perfectly readable XML.
It should be noted that XOR Encryption is quite possible and relatively easy to crack, especially since the key has to be stored as a part of the application, but it requires lots of time and effort to break through and doesn't qualify as encryption legally (eg. you shouldn't need to go through the whole Encryption Export thing when releasing the app), while still keeping the data gibberish-y enough to throw off most people - which is usually enough, unless your data is really sensitive, eg. if you're transferring payment credentials or similar.
Ive been around the hacking block where I see people able to pull out email passwords and ftp details out of programs and I was wondering whats the best bet to protect those details while not crypting my vb.net program.
Encryption is the only way to really stop the dedicated hacker. But if this is about passwords that the program needs to know itself for operation, then it will have to have the key embedded as well (or maybe download it from your server every time). So the dedicated hacker could still get to it. Same problem the content industry faces in their Digital Restriction Management efforts : the player needs to be able to decode the media, they need to give people the player, so the player can be disassembled, and the encryption cracked.
All you can do is obfuscate things a little (or a lot).
Or give up on client software and run your program as a web service, where people cannot get to the code.
Obfuscation and encryption may delay a crack, but only for a while, because every encryption system can be broken with:
Access.
Enough time.
Because an exact digital copy of whatever can be made in minutes or seconds, time is guaranteed, so #1 becomes paramount.
Never store passwords in software or databases!. Take a look at the SO Q&A about Salting Passwords for the details.