Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

iOS Can someone give me a high level overview of how to make RSA encryption work on iOS?

chrono1081

chrono1081

macrumors G3
Original poster
Jan 26, 2008
8,772
5,387
Isla Nublar
Hi guys,

I've been struggling for 2 months now trying to get RSA encryption to work on iOS and I feel that I'm missing some key pieces here and wondered if anyone can help clarify a few things for me. (I've never had to deal with encryption before so some of the stuff I say could be very incorrect.) My goal is to break this down into pieces and research and solve each piece.

My application has access to a modulus and an exponent which apparently together make the public key. It is to take these and use them to encrypt JSON data to be sent to a web server which holds the private key.

Apples documentation (and other places) show this being done with certificates, our app doesn't use certificates and instead just generates the encrypted data, which leads to:

Question 1: Is this the wrong way to do things? I'm not sure what the certificates actually do in these cases. Should I be using certificates instead of having the application have a modulus and exponent hardcoded?

Question 2: Here are the steps I think I need to solve in order for this to work. Can someone let me know if this is correct?

1. Generate a public key based on the modulus and exponent. (I'm not sure how to do this, people say use OpenSSL, Apple says don't use OpenSSL, I don't even know how I'd use OpenSSL from within my code).

2. Store that key in the iPhone/iPad keychain (It appears that you have to store them as a certificate, is that true?).

3. Use the SecKeyEncrypt functions to encrypt the JSON data (which appears to have to be converted to plaintext first).

4. Encode the encrypted data to base 16 which the web service expects.

If anyone has any tips, tricks, code samples, videos, book titles etc on how to do any parts of this it would be greatly appreciated. I have scoured Apples documents, Stack Overflow, GitHub, etc and nothing I have found seems to fully work. Thank you for any help you can provide.
 
Im interested in this as well
Just a note, you generate 2 keys, public and private, the private is only for the user, the public is there to share
 
Before I try to address your question, I'd like to add one:
How do you get a private key to someone without other people getting the same key?

Example:
If you wanted to send me a private key, what would stop someone else from getting the same key? Unless we met in person, what method of transfer would you use to get the key to the target?

Now for your question:

I'm not trying to be a nit-picker here, but I think you are talking about a few different things:

1. encrypting data
2. transferring data securely
3. getting the keys

So can we assume you have the level of encryption you want and are interested in transferring and getting the keys?

This might help:
Chap 14 from iOS 7 programming pushing the limits - Rob Napier / Nugunth Kumar / Wiley.
Chapter 14 Batten the Hatches with Security Services. . . . . . . . . . . . . . . . . . . . . . 239

Understanding the iOS Sandbox. 239

Securing Network Communications . 241

How Certificates Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Checking Certificate Validity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Determining Certificate Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Employing File Protection. 248

Using Keychains . 250

Sharing Data with Access Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Using Encryption. 253

Overview of AES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Converting Passwords to Keys with PBKDF2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

AES Mode and Padding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

The Initialization Vector (IV). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Authentication with HMAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Bad Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Combining Encryption and Compression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Summary. 260

Further Reading. 260

Apple Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

WWDC Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Other Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Click to expand...

Other Resources

Aleph One. Phrack, Volume 7, Issue Forty-Nine, “Smashing the Stack for Fun and Profit” (1996). More than 15

years later, this is still one of the best introductions to buffer overflows available, with examples.

www.phrack.org/issues.html?issue=49&id=14#article

Boneh, Dan. Stanford “Cryptography” Course. There is no better free resource for learning how to do

cryptography correctly than this course. This is not a quick overview. You’ll discover the math behind

cryptosystems and how they’re put together correctly and incorrectly. You’ll learn how to reason about

the security of systems and mathematically prove security theorems about them. It’s more math than

computer programming. I highly recommend it, but it is a significant commitment. It’s broken into two sixweek

sections.

https://www.coursera.org/course/crypto

Napier, Rob. “RNCryptor.” This is my framework for AES encryption, based on CommonCryptor. Its purpose is

to make it easy to use AES correctly, and it implements all the features discussed in this chapter.

https://github.com/rnapier/RNCryptor

Schneier, Bruce. Applied Cryptography (John Wiley & Sons, 1996). Anyone interested in the guts of

cryptography should read this book. The main problem is that after reading it, you may think you can

create your own cryptography implementations. You shouldn’t. Read this book as a fascinating, if dated,

introduction to cryptography. Then put it down and use a well-established implementation.

Williams, Justin. “SGKeychain.” This is my current recommendation for accessing the keychain.

https://github.com/secondgear/SGKeychain

/QUOTE]
Click to expand...
 
  • Like
Reactions: DennisBlah
DennisBlah said:
Im interested in this as well
Just a note, you generate 2 keys, public and private, the private is only for the user, the public is there to share
Click to expand...
How do you get the private key to the single user without others gaining access to it? Always wondered about that part.
 
KarlJay said:
How do you get the private key to the single user without others gaining access to it? Always wondered about that part.
Click to expand...
The user generates it himself/herself. A private key need not be sent anywhere. This is the whole point of private/public keys, as distinct from symmetric keys (secret keys), which require a secured distribution mechanism. That secured distribution may well be public-key infrastructure (PKI).

From a newly generated private key, the user also generates a public key, and maybe a certificate signing request (CSR) that includes info about himself/herself, and which is signed by the private key (hence, verifiable using the provided public-key). The CSR is sent to a Certificate Authority (CA), which produces a signed certificate and sends it back to the user. The signed certificate is basically a verifiable statement by the CA that whoever has the private-key corresponding to the certified public-key is the same as the other fields in the certificate (i.e. the principal).

This is all elementary public-key crypto. I suggest the first 2 chapters of Schneier's "Applied Cryptography", though there may well be shorter intros that explain the process adequately.
 
  • Like
Reactions: S.B.G and DennisBlah
KarlJay said:
How do you get the private key to the single user without others gaining access to it? Always wondered about that part.
Click to expand...
To be honest, I was asuming that the user generates its own key's and on some way setup a one time only transfer to your buddie with the public key, that matches the user's private one, but Im not into this part yet for my own projects yet at all. But at my work I create our company rsa keys monthly for interactive sftp from our costumers. I only send them the public key, as the private key is for the users thats going to connect to there, with the password of the private one

Im not sure, but I assume that when I create my rsa keys I will not hand over my private one, only the public (isnt that where private and public stands for? Public for handing out to others?)
 
Ok, still a bit confused about how the 1st connection takes place.

if person A want's to privately send data to person B, what's to stop someone else from seeing they very 1st key.

if A has the data and B sends a key what's to stop C from seeing and sending the same key?

As I understand it, the process is dependent on both A and B having some key that nobody else has. Yet they can't until they both have a key that nobody else has. Kinda like the chicken-egg problem, it has to have a starting point.

How do you establish a starting point that nobody else has access to?

If A requests a key from B, then what's to stop C from seeing this key and sending it to A telling A that they are B when in fact they are C? Assume the goal to be private data between A and B while keeping it from C.

I understand that the way Apple does this is by having people setup a private account, the account has a unique ID and the key is sent only to or from that ID. But what if you don't have an account with someone and want to send private data to them?

If someone is sniffing copies of all communications, they would know the original key regardless of who gives the 1st key.
 
KarlJay said:
Ok, still a bit confused about how the 1st connection takes place.

if person A want's to privately send data to person B, what's to stop someone else from seeing they very 1st key.

if A has the data and B sends a key what's to stop C from seeing and sending the same key?

As I understand it, the process is dependent on both A and B having some key that nobody else has. Yet they can't until they both have a key that nobody else has. Kinda like the chicken-egg problem, it has to have a starting point.

How do you establish a starting point that nobody else has access to?

If A requests a key from B, then what's to stop C from seeing this key and sending it to A telling A that they are B when in fact they are C? Assume the goal to be private data between A and B while keeping it from C.

I understand that the way Apple does this is by having people setup a private account, the account has a unique ID and the key is sent only to or from that ID. But what if you don't have an account with someone and want to send private data to them?

If someone is sniffing copies of all communications, they would know the original key regardless of who gives the 1st key.
Click to expand...
Basically, what stops C ("Eve" the eavesdropper, by convention) from seeing the same key is public-key cryptography (PKC). A fundamental feature of PKC is that the keys are asymmetric. That is, something encrypted with the public key can only be decrypted using the private key. Data encrypted using only the public key can't be decrypted by the public key; the private key is required. This is the essential concept.

Using PKC, Alice (A) sends Bob (B) her public key. Eve can see this. Bob now creates a random secret key (say, an AES key) to be used as the session key. After Alice receives this AES key, they'll both continue the conversation using AES crypto, not PKC.

After creating a random secret key, Bob encrypts it using Alice's public key and sends it in a message to Alice. Eve can see the message, but can't decrypt it because Eve doesn't have the private key. Alice has the private key corresponding to her public key, so she can decrypt the message and use the secret session key to continue conversing with Bob. No one else has Alice's private key, so no one else can decrypt the initial key-exchange message.

After a session key is established, the PKC keys need play no further role. Their essential purpose is in performing the initial session key exchange.

If both Alice and Bob need to start with a shared secret key, then that's conventional secret-key crypto. It's not public-key crypto.

Also see:
https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
 
Last edited:
  • Like
Reactions: DennisBlah and S.B.G
Ok, now I get it. It's harder to follow the words, but I found a video that makes it clear:

However, it seems that Eve could lie and say she's Bob. How would you know Bob is Bob. This must be why you have to have an account in order to start this. The process starts by going back to the owner of the account and unless you've hacked the account, you can't break the process.
 
KarlJay said:
Ok, now I get it. It's harder to follow the words, but I found a video that makes it clear:

However, it seems that Eve could lie and say she's Bob. How would you know Bob is Bob. This must be why you have to have an account in order to start this. The process starts by going back to the owner of the account and unless you've hacked the account, you can't break the process.
Click to expand...
That's a different problem. It's called authentication.

The specific attack (Eve impersonating Bob) is a simplified case of a set of attacks usually called "Man in the Middle" attacks (there's a Wikipedia article on it). All of the attacks involve the question of how Alice knows who she's really communicating with. Impersonation and MITM are essentially the same from the viewpoint of any one side. They differ only in the extent of what happens on the "far" side, away from Alice or Bob. MITM would an impersonator to both Alice and Bob in their conversation (i.e. bilateral impersonation).

PKC solves the authentication problem by having Certificate Authorities (CAs) trusted by all parties in a conversation, or a "web of trust" where principals represented by public-key certificates vouch for the authenticity of others.

https://en.wikipedia.org/wiki/Web_of_trust
https://en.wikipedia.org/wiki/Certificate_authority

Again, all of this is fundamental public-key infrastructure (PKI), and you should refer to a book or other reference for a detailed explanation. It will be far simpler and less likely for errors to appear if you use a known good (i.e. trustworthy) reference rather than Q&A's here.
 
  • Like
Reactions: S.B.G
dejo said:
Seems to me it would just be easier to get a certificate and then transmit the JSON over HTTPS. But, I admit I probably know much less about encryption than I suspect you do, @chrono1081.
Click to expand...

I doubt that! I've seen your posts, you know what your talking about.


Also a big thanks to everyone who responded.

Apple also responded on their forums and said that it would be bitter to have a server with security tools like OpenSSL generate a certificate that contains its public key and have my app grab that key, use it to encrypt data and send it back to the web service. The trick is convincing my workplace to do it this way.

From researching, Google and Microsoft suggest the exact same thing for encryption on mobile devices so it appears to be the industry standard way of doing things.
 
Just curious about all the data hacks going on... Was the hacked data not encrypted when it's stored on their servers? In other words, if each persons data is stored encrypted with a unique key, the data wouldn't have been readable without the key.

So is all this data hacking successful because companies aren't storing the data in an encrypted form? Or maybe it's because the keys are stored on the same servers and the keys aren't encrypted.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back