Re: file encription/decriptoin iOS
Re: file encription/decriptoin iOS
- Subject: Re: file encription/decriptoin iOS
- From: Alastair Houghton <email@hidden>
- Date: Mon, 26 Jun 2017 09:39:08 +0100
On 24 Jun 2017, at 21:12, email@hidden 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 (email@hidden)
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:
This email sent to email@hidden