You can use the iExplore app to look in the Documents folder of any device you attach to your Mac.
Also, data protection SUCKS because it locks the files if the app goes in to the background, basically suspending any file based background operations like sql db updates. We got burned on that badly in the past. Thanks to the help of Chris Thorman, I was able to update an AES256 hmac method to work with UTF-8 char sets. We use this for data security over http. Now, it might be overkill or just bad design, but we use a CoreData db with transformable property and encrypt the data stored. I can detail later if you wish. - Alex Zavatone Sent from my iPhone > On Jun 26, 2017, at 3:39 AM, Alastair Houghton <alast...@alastairs-place.net> > wrote: > >> 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/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ 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
