Exciting times lie ahead in the realm of cybersecurity! Today, we want to delve into the concept of crypto-agility and how it can empower organizations to fortify their security strategies against evolving threats.
What is Crypto-Agility?
Crypto-agility refers to an organization’s ability to swiftly adapt cryptographic algorithms, protocols, and cryptographic mechanisms in response to emerging threats or the obsolescence of existing cryptographic standards. It enables us to future-proof our security infrastructure and stay one step ahead of adversaries in an ever-changing digital landscape.
Why is Crypto-Agility Essential?
As technology advances and cryptographic algorithms mature, new vulnerabilities and attack vectors emerge. To safeguard our data and systems effectively, we must proactively address these challenges. By embracing crypto-agility, we can rapidly adopt stronger cryptographic algorithms or modify existing ones to maintain the confidentiality, integrity, and authenticity of our digital assets.
The Benefits of Crypto-Agility
Enhanced Resilience: Crypto-agility allows us to respond swiftly to cryptographic weaknesses, ensuring our security measures remain robust and resilient against evolving threats.
Regulatory Compliance: Many industry-specific regulations and standards mandate the use of specific cryptographic algorithms. With crypto-agility, we can seamlessly transition to new standards, ensuring compliance without disrupting business operations.
Future-Proofing: By building crypto-agility into our security architecture, we can adapt to the rapid pace of technological advancements and maintain a strong security posture even as new algorithms and protocols emerge.
Competitive Advantage: Organizations that embrace crypto-agility gain a competitive edge by demonstrating their commitment to staying at the forefront of security practices. This instills trust among customers, partners, and stakeholders.
How to Implement Crypto-Agility?
Continuous Evaluation: Regularly assess the effectiveness and integrity of your cryptographic algorithms and protocols to identify potential vulnerabilities or outdated standards.
Stay Informed: Keep a pulse on the latest advancements in cryptographic research and emerging standards to proactively identify areas where updates may be required.
Robust Infrastructure: Ensure your security infrastructure is designed to accommodate future algorithmic changes and seamlessly integrate new cryptographic mechanisms.
Collaboration: Foster collaboration with industry peers, academic institutions, and cryptographic experts to exchange knowledge, share best practices, and collectively address emerging challenges.
Inventorying: Understanding and managing your cryptographic inventory is an essential step towards maintaining strong security, ensuring compliance, and enabling effective crypto-agility. This topic will be subject of future post.
Embrace Crypto-Agility, Secure the Future
In this dynamic digital landscape, crypto-agility is no longer an option but a necessity. By adopting a proactive approach to crypto-agility, we can safeguard our organizations against emerging threats, stay compliant, and foster trust among our stakeholders. Let’s embrace this exciting paradigm shift and future-proof our security strategies together!
How to Implement Cryptography Governance in Your Company
The use of cryptography is becoming increasingly widespread as businesses seek to protect their data and communications. However, the implementation of cryptography can be a complex and daunting task. This blog post will provide an overview of cryptography governance and offer tips on how to implement it in your company.
Defining Cryptography Governance.
Cryptography governance is the process of creating and maintaining an organizational framework that enables decisions about the use of cryptography to be made in a consistent, timely, and cost-effective manner.
Why is Cryptography Governance Important?
Cryptography governance is important because it helps organizations to make informed decisions about when and how to use cryptography. By defining roles and responsibilities, establishing policies and procedures, and educating employees, organizations can ensure that cryptography is used in a way that meets their business needs and protects their data.
Sometimes organizations are investing a substantial amount of money in inappropriate products or services. A proper governance could avoid this.
Implementing Cryptography Governance in Your Company.
Before you can implement cryptography governance in your company, you need to define a policy and clear requirements. This policy and set of requirements should address how cryptography will be used within the company. It should also lay out the consequences of not following the policy.
Assign Roles and Responsibilities.
Once you have a policy in place, you need to assign roles and responsibilities related to cryptography governance. This includes identifying who will be responsible for managing cryptographic keys, implementing security measures, and overseeing compliance with the policy.
Educate Your Employees.
It’s important that all employees are aware of the company’s cryptography policy and understand their roles and responsibilities under it. Employees should be trained on how to use cryptographic tools safely and securely, and they should be made aware of the potential risks associated with improper use of cryptography.
Monitor and Review.
Cryptography governance is an ongoing process, not a one-time event. You should regularly monitor compliance with the policy and review it periodically to ensure it remains effective. You may also need to make changes to the policy as your company’s needs change over time.
When signing your code or data without applying a timestamp would result in having the signature being considered as invalid and trust warnings being displayed in case the certificate expires. This would mean that your signature is valid as long as your code or data hasn’t been tampered with and the certificate and/or its chain has not expired.
In order to avoid this from happening, you can apply timestamping. Timestamping will show that the signature on the code or data was valid at the time the signature and timestamp were applied. You can compare this with a notarized signature. The notary vouches that it was you and your signature at the time you sign the document.
This has the effect that even though the certificate may have been expired, the signature is not being considered as invalid due to the timestamping.
A timestamp is a key element to provide integrity and non-repudiation.
How does timestamping work?
A hash is calculated on the to-be-signed-code or data and sent to a Timestamping Authority (TSA).
The TSA will add to the hash some information, including the authoritative time and sign the whole with its private key, resulting in a timestamp token. This token contains all information that is required later to verify the timestamp. The token is stored with the original code or data.
With this information, any person or application opening the timestamped data or code will use the TSA’s public key to authenticate the TSA. The TSA public key will be found in the person or application trust store. A calculated hash on the original code or data will be compared with the original hash. If both hashes do not match, warnings will be shown indicating that the code or data has been modified since the timestamp has been applied and should not be trusted.
Timestamping Authority Standards and Protocols
RFC 3161 (Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)) provides the requirements a Third Party needs to meet in order to operate a Timestamping Authority.
The ANSI X9.95 Standard adds to the RFC with minimum security requirements for the effective use of time stamps in a financial services environment.
The ISO/IEC 18014 Standard series specifies time-stamping techniques. It consists of three parts, which include the general notion, models for a time-stamping service, data structures, and protocols.
ETSI EN 319 422 V1.1.1 (2016-03) – Electronic Signatures and Infrastructures (ESI); Time-stamping protocol and time-stamp token profiles
ETSI TS 119 142-3 V1.1.1 (2016-12) – Electronic Signatures and Infrastructures (ESI); PAdES digital signatures; Part 3: PAdES Document Time-stamp digital signatures (PAdES-DTS)
ETSI EN 319 421 V1.1.1 (2016-03) – Electronic Signatures and Infrastructures (ESI); Policy and Security Requirements for Trust Service Providers issuing Time-Stamps
A Public Key Infrastructure is a set of hardware, software, people, policies and procedures, required to issue, manage, distribute, use, store and revoke digital certificates.
There are three core functional components to a PKI:
The Certificate Authority (CA), an entity which issues certificates. This can be either in-house or delegated to a Trusted Third Party;
The repository for keys, certificates and Certificate Revocation Lists (CRL), usually based on a Lightweight Directory Access Protocol (LDAP)-enabled directory service;
A management function, typically via a management console.
There may be a separate Registration Authority (RA), an entity dedicated to user registration and accepting requests for certificates. The RA performs the process of collecting user info and verifying user identity.
Encryption
Encryption is the process of encoding information is such a way that unauthorized persons are unable to read the information, unless they are in the possession of the key to decode it. Encryption does not prevent interception of the data, but protects against unlawful access. Data is encrypted according to a specific algorithm which turns data into a Ciphertext. In combination with certificates, TLS (Transport Layer Security) and SSL (Secure Socket Layer) are the more frequently used protocols.
Plaintext and Ciphertext
Plaintext refers to information or data in an unencrypted, or unprotected, form. Ciphertext refers to the output of an encryption algorithm operating on plaintext. Ciphertext is unreadable without knowledge of the algorithm and a secret key.
Algorithms and Keys
An encryption algorithm is a step-by-step set of instructions that specifies precisely how plaintext is transformed into Ciphertext.
Asymmetric-key Encryption
Asymmetric-key encryption, also known as public-key encryption uses two keys, a of a public key for encryption and a private key for decryption. The public key and private key are mathematically related so that when the public key is used for encryption, the corresponding private key must be used for decryption. RSA and Elliptical Curve Cryptography (ECC) are the most common forms of asymmetric-key encryption.
Symmetric-key encryption
Symmetric encryption uses a single “key” for both encryption and decryption. The fundamental concern with this method is making sure that the intended recipient indeed is the one to receive the key. The most common form of symmetric encryption is AES. The advantage of this over asymmetric encryption is that it is quicker to encrypt/decrypt by using a smaller key for the same level of protection, and simple to understand.
Hybrid Encryption
Encryption which combines the strengths of both symmetric and asymmetric encryption, while avoiding their weaknesses. The public key is used to encrypt the symmetric key.
The public key is used to encrypt the symmetric key. This encrypted symmetric key is sent to the recipient. The recipient can use their private key to extract the symmetric key. Now both parties have the same symmetric key which can be used to encrypt and decrypt data.
PKI Functions
The most common PKI functions are issuing certificates, revoking certificates, creating and publishing CRLs, storing and retrieving certificates and CRLs, and key lifecycle management. Enhanced or emerging functions include time-stamping and policy-based certificate validation.
Issuing certificates
The CA signs the certificate, thereby authenticating the identity of the requestor, in the same way that a notary vouches for the signature and identity of an individual. In addition, the CA “stamps” the certificate with an expiration date. The CA may return the certificate to the requesting system and/or post it in a repository.
Revoking certificates
A certificate may become invalid before the normal expiration of its validity period. For instance, an employee may quit or change names, or a private key may be compromised. Under such circumstances, the CA revokes the certificate by including the certificate’s serial number on the next scheduled CRL. Storing and retrieving certificates and CRLs The most common means of storing and retrieving certificates and CRLs is via a directory service, with access via LDAP. Other options include X.500 compatible directories, HTTP, FTP, and e-mail.
Timestamping
In addition to the content and authenticity of a transaction, the exact time of the transaction can be important. For instance, a transaction may have to be submitted by a certain time to be valid. The solution to having trusted transactions is to combine digital signatures with time-stamps. This can be accomplished by augmenting a PKI with a time-stamping service.
Key lifecycle management
The PKI performs some functions, such as issuing a certificate and listing a certificate on a CRL, in response of a specific request. In contrast, key lifecycle functions, such as updating,backing up, and archiving keys, are performed routinely.
Updating Keys
New keys are usually issued at regular intervals, such as every two or three year, to reduce the exposure of those keys.
Backing Up Keys
Users frequently forget the passwords that protect their private keys; or they may “lose” the keys, for example, through a disk crash or virus attack. The company should be able to restore the keys to the user.
Archiving Keys
When employees leave the company, their encryption keys are invalidated for future use, while retaining the keys in order to access previously encrypted files and email messages. Keys used for digital signatures may be retained for as long as the signed documents, so signatures can be verified. Note that many organizations archive encryption keys but not signing keys, since the availability of archived signing keys could invite abuse via identity impersonation.
Automated Key Lifecycle Management: A Critical PKI Function
The effort required to manage keys manually can limit the scalability of the PKI. Automated key management is a critical function for a large PKI.
PKI Related Standards
PKI standards permit multiple PKIs to interoperate, and multiple applications to interface with a single, consolidated PKI.
In particular, standards are necessary for: Enrollment procedures;
Certificate formats;
CRL formats;
Formats for certificate enrollment messages (client requests certificate, server issues certificate);
Digital signature formats.
The primary focus of interoperable PKI standards is the PKI working group of the Internet Engineering Task Force (IETF).
X.509
The foundational and most universally supported PKI standards are ISO/IEC 9594-8 and RFC5280. The primary purpose of X.509 is to define a standard digital certificate format.
PKCS PKCS is a series of standards covering PKI in areas of certificate enrollment and renewal, and CRL distribution. For PKI interoperability, the three most important PKCS standards are PKCS #7, “Cryptographic Message Syntax Standard,” PKCS #10, “Certificate Request Syntax Standard,” and PKCS #12, “Personal Information Exchange Syntax Standard”.
Standards That Rely on a PKI Most major security standards are designed to work with a PKI. For instance, Secure Sockets Layer (SSL), Transport Layer Security (TLS), Secure Multipurpose Internet Mail Extensions (S/MIME), Secure Electronic Transactions (SET) and IP Security (IPSEC), all assume, require or allow the use of a PKI.
Hash Functions
A hash function is a mathematical function that converts a numerical input value into another compressed numerical value. The input to the hash function is of arbitrary length but output is always of fixed length. Values returned by a hash function are called message digest or simply hash values.
Compared to the (a)symmetric encryption and decryption, which are two way functions, hash functions are one way functions, meaning that from a digest, one can’t obtain the original message.
Hashing is often used to store passwords in a database, if used without salt, they are easy to crack since they result in the same digest for the same password.
Standard hashing
Hashing and Salting
A salt is random data that is used as an additional input to the hash function
Advantages of Hashing
It is mathematically impossible to extract the original message from the digest;
A slight change to the original message causes a drastic change in the resulting digest;
The result of the hashing algorithm is always the same length;
It is infeasible to construct a message which generates a given digest.
Digital Signature
A digital signature (not to be confused with a digital certificate) is a mathematical technique used to validate the authenticity and integrity of a message, software or digital document.
To create a digital signature a hash of the to-be-signed electronic data is generated. The private key is then used to encrypt the hash. The encrypted hash, along with other information such as the algorithm used, is the digital signature.
The reason for encrypting the hash instead of the entire message or document is that a hash function can convert an arbitrary input into a fixed length value, which is usually much shorter. This saves time since hashing is much faster than signing.
The value of the hash is unique to the hashed data. Any change in the data, even changing or deleting a single character, results in a different value. This enables others to validate the integrity of the data by using the signer’s public key to decrypt the hash. If the decrypted hash matches a second computed hash of the same data, it proves that the data hasn’t changed since it was signed. If the two hashes don’t match, the data has either been tampered with in some way (integrity) or the signature was created with a private key that doesn’t correspond to the public key presented by the signer (authentication). Digital signatures make it difficult for the signer to deny having signed something (non-repudiation) — assuming their private key has not been compromised. A digital signature does not guarantee confidentiality.
Digital Certificates
A digital certificate provides identity of a person, computer, system or organization. It allows those end-entities to exchange information securely over the internet. Digital certificates are generally issued by an official, trusted agency. The certificate contains the name of the certificate holder, a serial number, expiration dates, a copy of the certificate holder’s public key (used for encrypting messages and digital signatures) and the digital signature of the certificate-issuing authority (CA) so that a recipient can verify that the certificate is real.
To provide evidence that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority (CA). Operating systems and browsers maintain lists of trusted CA root certificates so they can easily verify certificates that the CAs have issued and signed.
Many digital certificates conform to the X.509 standard.
Types of Digital Certificates
Domain Validated Certificates
Domain Validated certificates are certificates that are checked against domain registry. There is no identifying organizational information for these certificates and thus should never be used for commercial purposes. It is the cheapest type of certificate to get, but this is a high risk certificate use on a public website. It is comparable to the “hooded man” or the zero star rating sellers. Visitors to a website with DV certificates cannot validate, via the certificate, if the business on the site is legitimate and thus often DO NOT trust this type of certificate. It is recommended using these types of certificates where security is not a concern, such as protected internal systems.
Organization Validated Certificates
Organizational certificates are Trusted. Organizations are strictly authenticated by real agents against business registry databases hosted by governments. Documents may exchange and personnel may be contacted during validation to prove the right of use. OV certificates therefore contain legitimate business information. This is the standard type of certificate required on a commercial or public facing website. OV certificates conform to the X.509 RFC standards and thus contain all the necessary information to validate the organization.
Extended Validation Certificate
Extended Validation Certificates are digital certificates that involves stringent vetting process to validate and verify if the entity which has requested for an SSL Certificate is legitimate. Users can see a green address bar if the website is secured with an authorized EV SSL Certificate. The green address bar builds customer trust and increases rate of conversion.
Nothing provides more trust and security than Extended Validation Certificates. It is used by most of the world’s leading organizations. They have found that switching from OV to EV certificates increases online transactions and improve customer confidence. It is no longer a luxury but a necessity.
Note: in some circumstances, even EV certificates can be fake.
Client vs Server Authentication Certificates
Server certificates are used to authenticate the identity of a server. When installed on a website, a server certificate turns the protocol on the website from HTTP to HTTPS and installs indicators that vouch for the authenticity of the website. Thus, users can know the website belongs to the said entity. Apart from authentication, server certificates also facilitate Encryption. Meaning, any information a user sends to the server is protected.
Contrary to Server certificates, Client certificates are used to validate the identity of a client (user). The user might be a website user or an email user. Simply put, it works as password, but without any intervention/input from the user. This way, the server makes sure that it’s connecting to the permitted user and that party is safe to communicate with. Client certificates also use public key infrastructure (PKI) for authentication, just like Server certificates. However, there is one significant difference between the two. Unlike Server certificates, Client certificates don’t encrypt any data; they’re installed for validation purposes only.
Certificate Authority (CA)
A CA issues and verifies certificates (see Digital Certificates). The CA takes responsibility for identifying (to a certain extent) the correctness of the identity of the person asking for a certificate to be issued, and ensures that the information contained within the certificate is correct and digitally signs it.
The CA could be seen as the PKI equivalent of a passport agency – the CA issues you a certificate after you provide the credentials they require to confirm your identity, and then the CA signs (stamps) the certificate to prevent modification of the details contained in the certificate.
Certificate Revocation Where a system relies upon publishing certificates so that people are able to communicate with each other, there has to be a system for letting people know when certificates are no longer valid. A system of revocation lists has been developed. This is a list of certificates that are no longer trustworthy (for whatever reason).
There are currently two different methods for checking for certificate revocation – ‘CRL’or ‘OCSP’. Revocation lists may be publicly available. This is because certificates may have been distributed for use beyond the private network of the organization involved.
Certificate Revocation List A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. CRLs are a type of blacklist and are used by various endpoints, including Web browsers, to verify whether a certificate is valid and trustworthy.
When a Web browser makes a connection to a site using TLS, the Web server’s digital certificate is checked for anomalies or problems; part of this process involves checking that the certificate is not listed in a Certificate Revocation List. These checks are crucial steps in any certificate-based transaction because they allow a user to verify the identity of the owner of the site and discover whether the Certificate Authority still considers the digital certificate trustworthy. There exists a IETF standard for CRLs RFC5280
Online Certificate Status Protocol Online Certificate Status Protocol (OCSP) is one of two common schemes for maintaining the security of a server and other network resources. The other is the Certificate Revocation List (CRL), described above. IETF has defined an OCSP standard RFC6960.
OCSP overcomes the limitation of CRL: the fact that updates must be frequently downloaded to keep the list current at the client end. When a user attempts to access a server, OCSP sends a request for certificate status information. The server sends back a response of “current”, “expired,” or “unknown.” The protocol specifies the syntax for communication between the server (which contains the certificate status) and the client application (which is informed of that status). OCSP allows users with expired certificates a grace period, so they can access servers for a limited time before renewing.
Conclusion
It is very difficult to draw any general conclusion about PKI because it can be used in so many different ways. Implementing an organization-wide PKI for multiple applications can be a serious undertaking, requiring significant investment and commitment, while deploying a dedicated PKI for, let’s say, securing communication between a few servers can be achieved with much lesser effort. One important element to be taken into the decision may be the question of operating your own CA or using an external CA.
Identifying the problem(s) that need to be solved is the primary steps one needs to take before deciding if a PKI is the right solution. Many problems can be solved with other technology that doesn’t rely on PKI. If, however, one needs to provision digital signatures, PKI is the only technology that is capable of supporting this in a secure and scalable way.
Applications utilize more and more the benefits of a PKI, as well from an interoperability viewpoint as from the ability to control a user’s credentials from within this widely used and standardized framework. This makes PKI very valuable, especially because of just one single place from which to withdraw the user’s privileges if that user leaves the company or any other circumstance.
We all know about the issue with the end-to-end encryption Zoom is having, as noted by Steven Bellovin in his blog post about Zoom, but besides that, there are ways to tweak or use Zoom in a safer way for video conferencing.
Avoiding uninvited guests
In order to avoid unwanted guests to join your conference, you may want to select the option to generate automatically a Meeting ID and not to use your personal Meeting ID.
Your personal Meeting ID may become public in some way and as such everyone have possession of it could join any future conference, even if not invited.
As additional security, you can choose to enable the ‘Enable Waiting Room’ option while creating your meeting. This will put participants in a on hold status until you allow them in. As such, unwanted guests can be detected and not allowed.
If you really want to lock down your conference, make sure your participants need a password to access the meeting. This can be set in the settings screen when organizing a meeting. Again, always be careful how and to whom you share this password.
All above options can be set for each meeting invite you make.
As a generic setting, via your Zoom settings, you could also restrict screen sharing, so that no-one except yourself can share applications or desktops.
While in a conference and once all invitees have joined the meeting, you can also lock your meeting, avoiding other, unwanted, participants to join.
The above measures will ensure that you can hold your conference calls in a safer environment then without setting them but understand that you are always at the mercy of your participants to handle the Meeting ID and corresponding, potential, password.Add paragraph text here.
Edit: In the mean time Zoom has applied some changes to the default settings to address some of the privacy concerns. These default settings are fully in line with what I described above. Lucky me 🙂
Most important links from the screenshot below: 2-minute video – FAQ
