How IoT Hub cryptographically validates the certificate chain for internal consistency and then issues a proof-of-possession challenge to the device ?
Please refer the following article that explains with an example on How X.509 Certificates are used in Azure IoT
Here is the section of the RFC article where it explains about proof of possession
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 have build a PKCS#10 Certificate request with proof of possession element that will be sent towards Certification Authority via ACS to obtain the User certificate. In Android app it is used the SpongyCastle package (SpongyCastle)
Has anyone any idea how to do that in swift?
Thanks
I found my solution!
Just used that library (https://github.com/cbaker6/CertificateSigningRequestSwift) and changed the function "buldCertificationRequestInfo" in order to have the certificate as was wanted.
I am trying to setup a Mosca server with SSL/TLS encryption.
Looking at the Mosca wiki at the page https://github.com/mcollina/mosca/wiki/TLS-SSL-Configuration suggests that we will require a private key and a certificate for the broker.
While that page is silent about the the configuration on the client side for the mqtt over SSL/TLS, I found an article by Mattino Collina himself on SSL/TLS configuration on the client side. Here http://www.hivemq.com/blog/mqtt-client-library-mqtt-js
This article states that for mqtts we need to provide a key and a certificate on the client side too. Should they be the same key and certificate that we provided while setting up the broker or different for every client that we connect to the broker?
Are these keys and certificates a way of authenticating the client for the broker?
How many certificates and keys depends on exactly what you are trying to achieve.
If you just need a secure connection then you only need a certificate and private key on the broker. (you may need to supply the CA certificate to the client depending on if you sign your own certificates or if you use certificates signed by recognised public CA).
If you want to uniquely identify the client via SSL then the client will also require it's own unique certificate and matching private key. These will be different from the brokers certificate/key pair, but probably signed by the same CA.
I have an asp.net mvc web app that has been running in production for about 4 years. Suddenly since about a week ago, I am getting this error being returned for all calls to 3rd-party secure API's:
System.Net.WebException: The underlying connection was closed: Could
not establish trust relationship for the SSL/TLS secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
This is for calls to SendGrid for sending emails, calls to Azure Blob Storage for uploading of documents, calls to Connect.io for logging.
I have managed to resolve the Azure Blob Storage problem temporarily by changing the connection string to use http instead of https.
Clearly something has broken on my app server, and I have no idea where to start looking.
Please help.
Edit:
Turns out I was using a sample library provided by one of my (lesser-used) 3rd party API's, and this library had an override of
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors)
which had it's own logic about what constitutes a valid certificate!!! AARGH!
This part become key information for your problem:
I am getting this error being returned for all calls to 3rd-party
secure API's
According to MSDN blog:
This error message is caused because the process is not being able to
validate the Server Certificate supplied by the Server during an HTTPS
(SSL) request. The very first troubleshooting step should be to see
if the server supplied certificate and every certificate in the chain
is trouble free.
Because it seems that one or more third party certificates are rejected, you may configure Trusted Roots part of your certificate trust lists to include all required third party CA as part of chain to work with secure APIs from trusted sources, including reissued certificates if any.
Further details: https://technet.microsoft.com/en-us/library/dn265983.aspx
NB (Optional):
As temporary measure, you can implement this certificate validation handler in WebRole.cs until all related third-party certificates has reissued (remember this setting will trust all issued certificates, hence it's not recommended for long term usage):
System.Net.ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
Additional reference: http://robertgreiner.com/2013/03/could-not-establish-trust-relationship-for-the-ssl-tls-secure-channel/
Similar thing happened in our system. Our problem was TLS version. The SSL offload appliance was configured to accept only TLS 1.2. One week ago this configuration accepted all TLS versions 1.0 to 1.2.
We had to reconfigure .NET's SecurityProtocol settings like:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
You can use this site to test which TLS version you are using: https://www.ssllabs.com/ssltest/index.html
Try to get some information about the certificate of the servers and see if you need to install any specific certs.
The server(s) may had a cert signed by a 3rd party CA which you hadn't trusted yet. The solution is to add that CA to the Trusted Root CA list.
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.