On 24 Jun 2017, at 21:12, yu...@aim.com wrote: > > I hope i am at the right place to ask for help on file encryption/decryption > for iOS. > > I need to encrypt a pdf file during download and to decrypt it for display > later on. Can i get some pointers about implementing the > decryption/encryption part ? or if there is any existing > decryption/encryption package or code i can use ?
Step back a bit; what’s the use-case for this? If you’re worried about protecting data at rest, iOS already does that automatically; see <https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/StrategiesforImplementingYourApp/StrategiesforImplementingYourApp.html#//apple_ref/doc/uid/TP40007072-CH5-SW21> Applications can’t directly access other applications’ files anyway, so the only remaining use-case would appear to be preventing someone else with physical access to the device *and* the ability to unlock it from downloading the data. Additionally, if you use a crypto layer on top of that, you’re going to have a problem, namely where to store the key. The only way you’re going to be *more* secure is if you derive the key from a passphrase using a Key Derivation Function (PBKDF2, for instance) and then ask the user for that every time - but it isn’t clear to me what the advantage of doing that is over getting the user to use a secure passcode for their device in the first place. If you *really* must do this, well, it’s quite complicated. You’ll want to use CommonCrypto (see “apropos 3cc” or “man CC_crypto” in a Terminal window) with AES, which is a block cipher, so you’ll need padding (see <https://en.wikipedia.org/wiki/Padding_(cryptography)>), which you’ll need to implement carefully and check when you’re reading the file - any errors with the padding should be a hard fail. If you just want to read the entire file in as one blob, you could use the default mode (CBC mode), but if you need random access for any reason you’ll need to build an implementation of CTR mode on top of CommonCrypto’s ECB mode (see <https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation>). You’ll also need to generate an IV (Initialization Vector) or nonce using a suitable random number source (/dev/random or SecRandomCopyBytes() are appropriate choices here; rand() or random() are not, nor is some dodgy function you came up with yourself, or *any* non-cryptographic RNG you looked up in a textbook); DO NOT USE ALL ZEROES FOR YOUR IV. You’ll need to store the IV with the file (e.g. as the first chunk of data). You’ll also need a nonce for your KDF, which also needs to be secure and also needs to be stored somewhere. You’ll need to think about whether there’s a single passphrase that unlocks all the data in your application (in which case you then need to consider whether using a single AES key for everything is good enough, or whether you want per-file AES keys, and in *that* case you need to know either (a) how you’re going to derive all those keys from the one passphrase, or (b) if you’re going to store them encrypted with a key derived from the passphrase). There’s a whole heap of complexity to think about here, and some of the answers may depend on exactly how your application works (e.g. whether an attacker could conceivably supply a PDF to it for encryption, or whether you can guarantee somehow - e.g. using SSL certificate pinning - that the PDFs only come from a trustworthy source). This is tricky stuff and given the question you asked, I’m honestly not certain you’re the right person to be implementing it --- I’d tend to recommend that you find someone with expertise in this area to help you, or at least give you some advice --- and you’ll need to start by carefully examining the entire system you’re building and looking to see what threats you’re trying to protect against. Personally, I strongly suspect that all of the above is unnecessary and that you can just let iOS protect your data for you. On the plus side, you’re unlikely to make your data any less secure than it is by default, and the default level of security is, I suspect, already sufficient for your needs. On the minus side, if you make a mistake anywhere in all of this, it might render the entire exercise totally pointless (i.e. you’ll have written an obfuscation layer, rather than something that genuinely provides extra security); in the very worst case, you might actually enable an attacker to cause your code to do something unexpected, though iOS does do various things (ASLR, non-executable memory) that make that harder. TL;DR: You probably don’t need to do this; what iOS does already is probably good enough for you. If you really *do* need to do this, given the question you asked, you should consider hiring an expert to help you to understand the threat model, to help you make appropriate choices, and perhaps even to implement the encryption layer for you. Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
