Your Network's Edge®
Blog Post
You are here
Zero-Touch Provisioning for uCPE – Part 2
Mar 11, 2019
The first part of this blog series laid the foundation of the security issues involving uCPE ZTP over public networks (and also in general). We also discussed the issue of authentication between the uCPE and the different network ZTP entities. It was argued that authentication, unlike privacy or integrity, must rely on prior knowledge of a secret (“what you know, what you have, what you are…”). The problem is that the provisioning of an authentication secret (e.g., a password or a PSK) is somehow contradictory to the general concept of zero-touch. Here, security certificates, embedded in the uCPE at its production or staging phase, can serve as a very good solution. Part 2 will focus on security certificates and their use in ZTP.
Before we address the security certificates themselves, we need to understand the concept of asymmetric key cryptography, also known as public key cryptography, which is the cryptographic method at the heart of security certificates.
Asymmetric key cryptography in a nutshell
As explained in part 1, symmetric key cryptography is based on the use of the exact same key Ks to encrypt and decrypt a massage. The encryption and decryption operations, that we shall mark here for convenience ƒ(Ks, x) and ƒ-1(Ks, x) (where x is the function input), though different, are using the same key. Hence, an encryption followed by a decryption process of some message m will be denoted by: ƒ-1(Ks,f(Ks,m) ≡ m.
In asymmetric key cryptography, two correlated[1] keys are generated: A private key KPr and a public key KPu. The private key can belong to a specific person or entity (e.g., uCPE) and is kept securely within this entity. The public key, on the other hand, can be distributed to everyone.
In order to send an encrypted message to someone (a person or a device), I need to use its known public key together with the encryption function e(Kpu, x) to yield the encrypted message. The recipient of the encrypted message would need to apply its private key together with the decryption function d(Kpr, x) to retrieve the original message: d(Kpr, e(Kpu, m)) ≡ m. Since only the legitimate destination has the private key that matches the public key with which the message was encrypted, only that destination will be able to successfully decrypt the original message.
Digitally signing a message, to allow the authentication of the message’s origin, is also very easy with asymmetric keys. In order to sign a message (or a document) of mine, all I need is to use my private key (known only to me) together with the signature function, and produce a digital signature for this message s(Kpr,m). The recipient of this signed message (message + signature) will be able to verify that the message really came from me (i.e., authenticate my signature) by applying the verification function together with my known public key to the message signature: v(Kpu,s(Kpr,m)) ≡ 1 .
Digital signature using asymmetric key cryptography
As you can see, by using asymmetric key cryptography, there is no need to pre-provision the participating end-points with secrets prior to the communication establishment. As long as the end-points have their {Pr,Pu} key-pair in place, all cryptographic operation can be conducted without exchanging a single secret key.
The most commonly known public key algorithm is the RSA that was invented by Rivest-Shamir-Adleman back in 1978. Since then, additional asymmetric cryptography algorithms have been developed, such as the Elliptic Curve Cryptography (ECC) that was suggested independently by Neal Koblitz and Victor S. Miller in 1985. Nevertheless, RSA remains the most ubiquitous digital signature algorithm today.
At this stage, you might already be asking yourself: “all this is very nice, but who exactly provides the key-pairs for a specific entity (a person or machine)?” Furthermore, once a key-pair is provided to me by some “key management entity”, how can I prove to the world that I am the legitimate owner of that key-pair? Indeed, as public key cryptography is based on the fact that each entity is provided with a secret private key as well as a “known to everybody” public key, the question of managing all of this becomes very important.
Security certificates and PKI
A security certificate (defined by ITU-T X.509) is a digital document (basically a file) that binds a specific entity (“Subject name” field inside the certificate) with a public key (“Subject Public Key” field inside the certificate). Hence, by using such a certificate one can prove to the world that they were assigned with a specific public key. The certificates are assigned by certificate management entities called Certification Authorities (CAs) that also apply their digital signature to the certificates using their own private key. This certificate management and distribution mechanism is called the Public Key Infrastructure (PKI). A PKI is a system for the creation, storage and distribution of digital certificates, which are used to verify that a particular public key belongs to a certain entity. The PKI creates digital certificates which map public keys to entities, securely stores these certificates in a central repository and revokes them if needed.
Public Key Infrastructure (PKI)
A CA can be a trusted global entity (e.g. Symantec Corp) that assigns, for a fee, certificates to organizations, such as banks, companies, educational institutes, web sites, etc. CAs can also have a more local nature, belonging to an organization (again, commercial, educational or government) with a limited scope of providing certificates to the internal infrastructure of the organization only.
Whatever their scope is, CAs always have their own X.509 certificate (binding their own name with a public key), as well as a matching private key that is securely stored and is never revealed. The CA will use this private key to sign certificates for other entities. The CA certificate itself is usually ‘self-signed’ and provides the PKI root of trust for the entities whose certificates have been signed by that CA[2].
Validation using PKI operates in the following manner: Whenever an entity is requested to prove its identity, it will first send its own certificate to its validating peer. The validating peer will examine the entity’s certificate and (after making sure it has the correct format) will see which CA was used to sign the certificate (this information is also part of the certificate). Assuming the validating peer has access to the self-signed CA certificate (and assuming, of course, that the validating peer trusts that CA), they will be able to use the public key of that CA (which is part of the CA’s certificate) to validate the authenticity of the entity’s certificate as explained above. Once that happens, the validating peer can use the public key inside the certificate to validate the authenticity of the entity itself. This forms a chain of trust starting from the trusted CA and ending with the entity proving its identity.
Put in simpler terms, an entity authenticity validation using PKI is comprised of: First, validating the authenticity of its certificate using the certificate of the CA that issued it, and second, once we know that the entity’s certificate is valid, validating the entity itself using its own certificate. In that sense, PKI-based authentication is using both something only I know (a private key) and something I have (a signed certificate).
The use of certificates greatly simplifies the authentication process as it does not mandate the use of temporary passwords or PSKs to be provisioned into the device prior to ZTP. Nevertheless, in order to work, certificates (both for the device and the signing CA) must be enrolled to the device as part of an early production or staging process. The good news is that once you’ve gone through the trouble and enrolled certificates to the device, they may be used later on to open ALL the device’s secured connections. Of course, if even greater security is demanded, a number of device certificates (each associated with a different private key) can be enrolled to a specific device (for example, one to open SSL/TLS connections and the other for IPsec).
Certificate enrollment to a device is performed in practice by forming a connection from the device to some CA server in the network. The device will usually generate an asymmetric key-pair and use its public key to generate a Certificate Signing Request (CSR) to the CA server. The CA server will receive the CSR and, after validating its format and details, will sign it and return the signed certificate to the device. This process can be carried out manually by importing/exporting files to/from the CA server or via more automatic certification enrollment protocols like the Simple Certificate Enrollment Protocol (SCEP).
Now that the security issue is covered, we need to make sure that the uCPE OS will be, as any piece of software, correctly licensed during the ZTP process, in order to allow its full functionality once ZTP is completed.
Check out our next blog post for more on uCPE OS licensing.
[1] Cryptographically correlated.
[2] It is allowed for a CA certificate to be signed by another CA. Hence, a hierarchy of CAs, sometimes referred to as the ‘chain of trust’, can be formed. However, the highest CA in the hierarchy is always self-signed.
About RAD's Blog
We’ll be blogging on a wide range of hot topics affecting service providers and critical infrastructure network operators. Our resident experts will be discussing vCPE, Cyber Security, 5G, Industrial IoT and much, much more.