Enterprise applications and PKI – Part 1

In an earlier article, we defined Public key infrastructure (PKI) as a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. We also identified some of the trends in digitalization which have been driving the adoption of PKI. As the adoption of PKI increases, enterprises need to understand which of their applications need to be “PKI enabled”. In other words, enterprise architectural blueprints should clearly identify the application scenarios to use PKI, and also flag non-conforming scenarios as potential security risks. In this article, we look at some of the typical application scenarios leveraging PKI in order to protect the enterprise and lower its risk profile.

1. Public facing websites and web applications: The padlock symbol in the URL bar of any web browser is now a de-facto requirement for any public facing website and application. The padlock represents an SSL/TLS (Secure Sockets Layer / Transport Layer Security) encrypted connection between the browser and the website that is set up using a digital certificate being sent from the website or web application server to the browser. The certificate confirms the identity of the website or web application to the browser. How does the browser know whether the certificate itself is valid and genuine? It verifies that the certificate has not yet expired and has been issued and ‘signed’ by a trusted third party, called a Certificate Authority (CA). Once the certificate is verified, the browser sends its public key across to the server, which uses this to encrypt the data that is sent back to the browser. The browser decrypts this data using its private key. All this magic happens seamlessly in the background, courtesy of PKI.
2. Virtual Private Network (VPN) services: The need to access an enterprise network remotely (for example from a different office location or a partner location) has existed for quite some time. The typical solution for this need is a leased line – a dedicated physical line between the remote location and the enterprise network. However, the leased line approach is not feasible for individual remote workers who need to access the enterprise network, such as employees who need to work from home. This is where VPN services, with the ability to provide a secure, encrypted communication channel for access to the enterprise network over the internet, have become extremely popular.
   When a remote user accesses the enterprise network through a VPN, a single authentication mechanism for example with a username and password is not secure enough. Multi-factor authentication (MFA) is important – with one of the authentication mechanisms being a digital certificate. The VPN channel (or ‘tunnel’) is set up only once the certificate validation is completed, as described earlier in this article.
3. Mobile applications: With every member of the workforce carrying at least one mobile device (and often more than one) and distributed teams (“work from anywhere”) becoming increasingly common, Enterprise mobility is on the rise. Mobile Device Management (MDM) platforms address some of the requirements of enterprise mobility by providing the ability to provision devices, manage mobile applications, and enforce the enterprise security policy on the device. However, authentication of mobile devices and users remains a challenge. An approach solely based on username and password is just not secure enough and the best way to ensure user identity. Mobile device validation and encrypted communication between the device and the enterprise network, using digital certificates is a far superior approach. Both the main mobile operating systems today i.e. iOS and Android, offer native support for digital certificates.
4. Software applications:Code signing: Companies who need to distribute software and the associated upgrades and patches to their customers, partners or employees usually do so today over the internet¹ . This however has brought new challenges to the forefront. Earlier, software that was distributed on physical media such as compact discs (CDs) was shrink-wrapped i.e. packaged in a box and physically sealed. Any tampering with the packaging and seal helped to alert the user. However, when the software is distributed over the internet, how does a user know whether the software (s)he is downloading is from the actual author? How does the user know that the software has not been tampered with and some malicious code or malware inserted into it? Code signing provides the answer to these questions. Any company that wishes to distribute software over the internet uses a code signing certificate to digitally sign the software. At the client side, the browser being used for the software download and the operating system (OS) on which the software is being installed, validate the code signing certificate and verify its authenticity. If the software has been tampered with, the user is alerted immediately. Without code signing, depending on the browser security settings, the user might get an alert, or the software may not get downloaded at all. If the user ignores the warning, downloads the software and attempts to install it, (s)he gets another warning, this time from the OS, that the publisher of the software could not be verified. As a result of these warnings, users may choose to abort the download, or abort the installation of the software – which is why it is important for companies to ensure that they sign the software that they publish. These are some of the enterprise application scenarios that need to use PKI. There are a few others – these will be covered in part 2. Stay tuned!