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

Discussion in 'iOS Programming' started by chrono1081, Jul 16, 2015.

  1. chrono1081 macrumors 604

    chrono1081

    Joined:
    Jan 26, 2008
    Location:
    Isla Nublar
    #1
    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.
     
  2. DennisBlah macrumors 6502

    DennisBlah

    Joined:
    Dec 5, 2013
    Location:
    The Netherlands
    #2
    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
     
  3. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #3
    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.
     
  4. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #4
    How do you get the private key to the single user without others gaining access to it? Always wondered about that part.
     
  5. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
  6. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #6
    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.
     
  7. DennisBlah macrumors 6502

    DennisBlah

    Joined:
    Dec 5, 2013
    Location:
    The Netherlands
    #7
    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?)
     
  8. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #8
    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.
     
  9. SandboxGeneral Moderator

    SandboxGeneral

    Staff Member

    Joined:
    Sep 8, 2010
    Location:
    Orbiting a G-type Main Sequence Star
    #9
  10. dejo Moderator

    dejo

    Staff Member

    Joined:
    Sep 2, 2004
    Location:
    The Centennial State
    #10
    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.
     
  11. chown33, Jul 17, 2015
    Last edited: Jul 17, 2015

    chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #11
    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
     
  12. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #12
    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.
     
  13. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #13
    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.
     
  14. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #14
    You're right, yet another complex topic to study :D I've always been interested, but never dug into it much.
     
  15. chrono1081 thread starter macrumors 604

    chrono1081

    Joined:
    Jan 26, 2008
    Location:
    Isla Nublar
    #15
    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.
     
  16. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #16
    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.
     

Share This Page