The second installment in our 5 part series details a presentation made by senior architect Chad Mckee about securing transportation data.

At Yahara, we work in a specific aspect of transportation called vehicular telemetrics. All trucks on the road today collect metrics on the performance as well as location using GPS. This means that large volumes of information are collected constantly, including videos, and sent to fleet management portals for review. In order to support our clients, we created a system based on our tried and true Yahara Framework that aggregate that data and provide various types of reporting to operations, to the fleets, and manufacturers of the trucks themselves to help them understand usage patterns.  In this particular case we used our integration framework to collect the data, transform the data, and send it to a portal for visualization.

Because telemetrics has many system to system actions, all connected via web service API, or file transfer protocols, there were many security aspects to consider during implementation. One of the goals of any project like this is to make sure that no one is listening in on the connections we have and gathering the data that is being transferred. One way we do this is with a certification. A certificate is used to create a tls or ssl connection between the client system and the server. When establishing these connections, the server presents to the client a certificate and then the certificate is validated by the client system by checking the domain is correct, the certificate is not expired, and validating the signature.  A digital signature placed on each certificate to validate them. After validation the next thing the client does is to make sure the certificate is not revoked because it could be revoked at any time. If everything is as expected, a public key is used to determine a private encryption key so communication can take place safely.

Encryption is only one side of the coin though, trust is involved too. Anyone can create a certification and anyone can use it. We need to know that the certificate is valid, no one else has it, and no one is listening to the information. Applications of this scale make creating a certificate for each client untenable. There would be too many certificates created. So we use third parties called certificate authorities (CAs), of which there are thousands. When we use one, the CA validates that you were making the request, you are the owner of the app, and you have a certificate for the domain. If all that checks out they will send a certificate with their signature with a private key. When your OS receives this certificate it checks it against a certificate root store. Whenever it receives them, it matches it to the root store signatures. If it finds it, the certificate gets accepted and the connection can continue.

To access data flowing from one system to another, attackers frequently use what is called a man in the middle attack to circumvent certification. If a key is compromised or lost, or someone creates a false CA, whoever has that key can generate a certificate for your domain and redirect your traffic to them. This creates a connection between the client system and the attacker allowing them to decrypt and re-encrypt. In this way they can access all the data that you are trying to send securely and privately and you wouldn’t know because you would think the CA was a trusted source. So an issue with certificates and CA's is making sure you know who you are trusting. 

 If you want to trust less you can use certificate pinning, which decreases the world of trust down to CA’s you specifically select to trust. To do this you would make the application aware of the certificates it should expect. So the application will actually say that it will only accept certificates from certain authorities. This creates some extra maintenance however, because you will need to update the application of a certificate is revoked or expired to make sure it is looking for the new signature and certificate

Using technology such as certificates and certificate pinning can help mitigate risk of a man and the middle attack and secure our cloud communication processes. Increasing security  is one of the reasons why customers may choose to use custom technology, because it can be tailored to address specific security concerns (e.g. with certificate pinning). 

Take home points:

•       Certificates are used to establish and SSL/TLS connection.  This is implemented through a “trust chain” provided by the operating system.

•       In some cases, it is necessary to assert specific authority chain requirements at the application level, this is called “certificate pinning”.

•       When managing your trust chain at the application level, you also need to take on operational responsibility for trust chain scenarios, such as adapting to certificate revocation events