I read through the 'Local Attestation' sample code. I got the idea that local attestation can construct a secure channel for transmitting private data. However, I didn't see anything related to checking the code and make sure the code running in the Enclave is safe. For example, if Enclave 2 is trying to connect Enclave 1, how will Enclave 1 make sure Enclave 2 will not leak any private information it received from Enclave 1?
The goal of attestation in SGX is, citing Intel's original paper, to provide "a mechanism by which another party can gain confidence that the correct software is securely running within an enclave on an enabled platform".
From your original question, I identify three main flaws:
The goal of attestation is not to create a secure channel for transmitting data.
The basic local attestation is a one-sided process. Enclave 1 proofs his identity to Enclave 2.
Generally, when talking abot Trusted Execution Environments (like SGX) you always trust what's loaded inside an enclave. This is, SGX won't protect against a malicious application running inisde an enclave.
Through the attestation process, Enclave 2 can validate all the code and data running in Enclave 1. Observe that, if the symmetric process is followed as well, both Enclaves can validate the code and data running in the other enclave. Additionally, and since you brought it, there's a mechanism to exchange a shared secret through this local attestation process that enables establishing a secure channel among two attestated enclaves.
But in short, you must trust what you load inside the enclave.
In order to do this you have to check the identity of the peer enclave (this is done here and here in the LocalAttestation sample).
The Local Attestation sample ensures the secure channel is established between two enclaves (enclaves protect the code they're running), and before using the secure channel you should check you're communicating with a trusted enclave, that is an enclave running code you trust, or signed by a trusted author.
The function doing this identity verification is defined here.
Related
I'm creating a coap server with DTLS as security layer that will use digital certificates, x509.
The Coap Server is a data bridge to a cloud server (CA) that uses x509 as authentication.
I also have a device that directly connects to the Cloud server using the same authentication method.
A couple of functions of the device, also needs to communicate with Coap server.
Thus the cloud server is the CA for issuing digital certificates both the device and the Coap data bridge.
I wanted to reuse the certificates (used to communicate to the Cloud Server) in device for connecting to the Coap server. Since the the device is a constraint thing, having multiple certificates are not advisable. Is this possible?
Yes, but there are some pitfalls:
RFC7252 - DTLS - x509
Implementations in Certificate Mode MUST support the mandatory-to-
implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified
in [RFC7251], [RFC5246], and [RFC4492]. Namely, the certificate
includes a SubjectPublicKeyInfo that indicates an algorithm of
id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the public key
format is uncompressed [RFC5480]; the hash algorithm is SHA-256; if
included, the key usage extension indicates digitalSignature.
Certificates MUST be signed with ECDSA using secp256r1, and the
signature MUST use SHA-256.
So, you either use ECDSA (ECC certificates, not RSA), or you need to check, if your server is able to handle it. For Eclipse/Californium the node's certificate must be ECDSA, the other certificates in the path may use other algorithms, if they are supported on your platform.
By the way, I'm not sure, if you really benefit from x509, but that depends on the platform your using on your devices.
X509 certificate and key could be used for several purposes. Examples include,
digital signature
key enciphering purposes
data enciphering purposes
key agreement
so on and so forth
More details could be found here
Now, as per to the description of your problem, you are inquiring whether to use the same certificate/key pairs for both to
Authenticate against the cloud server
Use it for communication ( Encipher/Decipher) purposes with the COAP server
Ofcourse you can use it as long as the (KeyUsage) extension specifies the intended use of the certificate. Refer link above for KeyUsage extensions in X509 certificates
I need to store an encryption key within my app, so that it can use the same key to encrypt and upload data, and download and decrypt data, from a public store. That way, the data can't be read by any other party in between.
What I'm concerned about is the potential for somebody to hijack my app. Once my app has been archived, would it be possible for someone to read a hardcoded encryption key held within the app?
If the key is in the app bundle there is a chance it can be discovered and doing this is not secure. As #Cristik states authenticate the user to the server and download the key at that point.
To secure the key the best you can do is to save the key in the Keychain.
Protecting against the owner of the device is very difficult and falls more under DRM.
Protecting against an non-owner depends on the owner having set a good passcode/password.
Protecting against data in transit (upload/download) is easy, use https, ensure the server is current (TLS 1.2 and Perfect Forward Secrecy) and pin the server certificate in the app.
Update:
In the ipa only the executable files are encrypted so other files can be accessed from the download. If a file is encrypted the attacker will need the encryption key and that can be strong: random bytes.
But the app needs the encryption key so the problem is how can the app know the key and not an attacker. Encryption does increase the work factor be the need to obtain the key.
There are disassemble tools so if the key is in the code it can be found by an experienced attacker.
If the key comes from a server it is not coded into the app so the work factor again increases. A MITM attack can be used to see the key in transit and pinning the certificate and using current https best practices can mitigate this attack vector.
Finally the key is in RAM memory at the time of decryption and can be found but again the work factor is increased.
In general what is necessary to protect data at the highest levels is complicated, requires special hardware and physical security.
Bottom line: determine the level of attacker you are defending against and the value of the data; code to that level. Do not underestimate the attacker.
Instead of storing the encryption key within the application bundle, you can request it from a server via a secure connection (HTTPS), and then save it in keychain for later retrieval.
You can add more security layers to the https connection by adding SSL pinning or/and other security measures.
Plus, you can generate different encryption keys every time the user logins, and if the store API supports it, you can invalidate all keys generated for a user if for example his phone is stolen.
I want to proxy traffic from an ios application to Fiddler (or Burp). It looks like the application sends a client certificate to the server.
I will need to retrieve this cert from the phone(it's jailbroken) and import it to my proxy. Is there a way to do that ?
The client certificate is used to identify the client. If the programmer of the app made his job well, you will face difficulties (hopefully). Likely, and most secure, the private key and identity resides in the key-chain. Less secure, it resides in a secured archive (.p12, .pkcs12, .pfx) in the bundle, whose password resides in the key-chain.
If the programmer did his job not so well, you might find the password of the secured archive in the clear somewhere in the apps binary (there're actually floating samples around which do exactly this).
I have seen many examples on verifying client or server certificates using Security framework APIs but this will solve only problem of Identification of security features but what about Confidentiality of data? How do I exchange private and public keys between client and server? What about Interception, Modifications, or Fabrication attacks? What if someone pretending and sending correct certificate as expected by client?
Identification is provided by verifying the cert as you note. Confidentiality is provided via encryption. Authentication is provided by signing the data. Together they are often implemented via TLS over a network connection.
In short, if you properly implement and deploy HTTPS, and validate your certificates, then you will get all of the things you're describing. NSURLConnection will do almost all of this for you by default if you just use an "https" URL.
If you deploy a certificate on the server and protect its private key, then it is not feasible for an attacker to pretend to have that certificate. Only the server has the server's private key (it is up to you to protect the private key from copying or theft).
A typical approach is to use a commercial certificate, in which a certificate authority (CA) like Verisign attests that the private key was issued to the owner of a given host (known as the CN or common name). This is a simple-to-use approach and generally cost effective. Go to one of the well-known CAs and buy a cert.
However, you can also create your own public/private server keypair, protect the private key, and distribute the public key in your client. You can then configure your client to only accept that one certificate and no others. This is actually more secure than the commercial certificate. For an example of this, see SelfCert. This is from my CocoaConf-RTP-2012 talk. I'll be giving a similar talk at CocoaConf-DC-2013. It is also discussed at length in chapter 15 of iOS:PTL.
Client certificates are less common. They are used to authenticate the client, not the server. For a client certificate to work correctly, each client must have its own certificate. You can't ship a private key as part of your bundle. If you do, anyone can use that private key to impersonate a client. (Conversely, it is completely fine to put the server's public key in the bundle. It's public; you don't care who sees it.)
With CFNetwork, after connecting, you would need to use CFReadStreamCopyProperty to fetch the kCFStreamPropertySSLPeerTrust. You could then evaluate the returned SecTrust object. That said, I recommend the NSURLConnection code if you can use it. If you need lower-level access, you could still use NSStream. Jeff Lamarche discusses this in NSStream: TCP and SSL. But I'd recommend a tool like AFNetworking or CocoaAsyncSocket instead if you need lower-level control over TCP+SSL.
Okay, so look at this diagram.
There are two little boxes, that signify how a given profile should be signed.
In Phase 2, step 1, it says "Apple issued certificate", but it doesn't say which apple issued certificate (they issue more than one). I have tried my developer certificate and the MDM (APNS) certificate. It wasn't one of those. Is there a third magic certificate I somehow need (and how do I get it)?
In Phase 3, step 2, it says "Identity certificate", but again it's a little sketchy on the details. The only identity certificate I know of is installed on the device, using the device's private key, how is the server supposed to use that to sign a profile?
The only way I've gotten this to work, is by creating my own self-signed certificate, and pre-installing it on the device. Obviously this is not an elegant or particularly secure way to do things.
Follow up questions
My server certificate is issued by "DigiCert High Assurance EV Root CA" and is on the list: http://support.apple.com/kb/ht5012, but iOS 6 devices consider it "untrusted" when signing profiles, but just fine for SSL which is wierd. iOS 5 devices are fine though. Any idea why?
I don't really understand the encryption bit either. From the MDM documentation: "Each device must have a unique client identity certificate. You may deliver these certificates as PKCS#12 containers, or via SCEP. Using SCEP is recommended because the protocol ensures that the private key for the identity exists only on the device."
While I agree it is ultimately more secure that only the device itself knows its private key, it's somewhat problematic as a 2048-bit public key can only be used to encrypt about 100 bytes of data, which isn't enough for even the smallest possible payload.
Let me go over phase 2 and phase 3 first
In the Phase 2, step 1, iOS device will send to a server response which is signed by device certificate/key (each device comes with preinstalled certificate/key which is different for each device). These on device certificates/keys are issued by Apple.
On the server side, you should verify it using Apple Root Cetificate.
In the Phase 2, step 1-3 your profile service will send a SCEP request. This SCEP request contains information to let device know to which SCEP server it should talk. This SCEP server is your server. So, a device will talk to this SCEP server and will request new identity certificate from it.
In Phase 3, step 2 device response will be signed with certificate/key of this identity certificate. And now you should verify it with your Certificate authority root certificate. (One more note SCEP server in Phase 2 is kind-of proxy to yours Certificate authority)
And now answering your questions "MDM profile signining, which certificate to use?"
MDM profile could be encrypted and/or signed.
If you want to encrypt it, you encrypt it using identity certificate associated with this device. So, device which has a key for this identity, so it can decrypt it.
If you want to sign it, you sign with your server key. Device should have a server certificate installed, so it can verify signature.
BTW. On this subject. One thing which isn't shown on this diagram, but usually is requited - first step (before whole this enrollment) is usually installation of server certificate (for future profile signature verification). Potentially, you can skip this step if your server certificate is issued by well known CA (as example Verisign or something like that).
Let me know, if you have any followup questions. It took me a while to understand whole this OTA/MDM enrollment.
Update 1
I don't know why iOS 6 treat your certificate as untrusted for signing. I didn't work with certificates which were signed by well known CA's.
I have only one guess. It could be that between iOS 5 and iOS 6 they changed something regarding key chain. Generally speaking, each app has it's own key chain. And all well known certificates, I believe should be stored in Mobile Safari keychain. It could be that MDM/Preferences shared this keychain with MobileSafari in iOS 6 and now they don't share it.
In such case, you will have to install this "DigiCert High Assurance EV Root CA" through a profile (to put it in correct keychain). However, it's wild guess.
Regarding encryption. First of all, you are right, if each device has it's own private key, it's way more secure. In such case, if anybody will steal a profile they won't be able to decrypt it (because only a device has a private key to do so). This is especially critically, if you are sending down profiles which are sensitive (as example, email account with both user name and password).
Very high level introduction into cryptography:
Any key (with any length) can encrypt data of any length. All encryption algorithms are designed that way that you can use the same key to encrypt any amount of data.
Asymmetric algorithms (like RSA) rarely used to encrypt data directly. In most cases, this algorithm is used to encrypt a key for symmetric algorithm (as example AES) and all following encryption/decryption is done using AES. There are two reasons for that: performance (AES is faster then RSA) and resources (AES is less resource hungry than RSA).
So, as result, if you need to encrypt profile you use PKCS7, which is internally uses RSA, AES (or other algorithms). Usually, you have a library to do this (OpenSSL or BouncyCastle). So, you don't have to figure out all these complexities.
BTW. If you have questions which aren't good fit for SO, you are welcome to contact me directly (my contact info in my profile).