First Look: The InterSystems Public Key Infrastructure (PKI)This First Look introduces the InterSystems public key infrastructure (PKI), which can play an important role in developing your organization’s security strategy. It presents information about public-key cryptography, certificate authorities, and PKI. It then walks through some initial tasks associated with using the InterSystems PKI. Once you’ve completed this guide, you will have created a certificate authority (CA), and then requested and received a certificate from it for a CA client. Show
While the InterSystems PKI is not for use in production systems, you can use it to become familiar with PKI tools and security infrastructure generally. This can be particularly helpful as part of the design and exploration process for creating a comprehensive approach to security. This guide uses InterSystems IRIS® data platform default settings, which allows you to acquaint yourself with the fundamentals of the PKI without having to deal with other details that are important when performing an implementation. For the full documentation on database encryption, see The InterSystems Public Key Infrastructure. To browse all of the First Looks, including those that can be performed on a free evaluation instance of InterSystems IRISOpens in a new tab, see InterSystems First LooksOpens in a new tab. Why a PKI Is ImportantThe frequency of news about security breaches at many organizations makes clear the need to secure their communications. Organizations need to protect data that is traveling from one site to another or when there needs to be some kind of verifiable, legally binding digital signature. Powerful, effective, and pervasive tools to address these and other needs are public-key cryptography and public key infrastructure (PKI). Public-key cryptography enables the encryption and decryption of data. This provides a means of performing various actions related to securing data. These include protecting data in transit on an unsecured network (such as the Internet) or establishing the provenance of a document. It thereby enables crucial technologies, such as Transport Layer Security (TLS) and is the means by which browsers protect our connections to web sites. Public-key cryptography operates on data controlled by distinct entities, where entities can be people, applications, organizations, and so on. However, public-key cryptography alone does not provide sufficient confidence of the identity of these entities in activities, particularly if they do not know each other personally. To achieve that level of confidence, there needs to be a larger structure that also provides trustworthy and verifiable identification information for entities involved. Such a structure is known as a PKI. A PKI establishes a means for entities to be confident of each other’s identities, even without any direct personal knowledge of or contact with each other. This requires each entity to trust a third party — called a certificate authority (CA) — that vouches for the identity of the other entity (also known as the other peer). With a PKI, entities can perform meaningful and legally binding cryptographic operations, which include encryption, decryption, and digital signing and signature verification. InterSystems provides a public key infrastructure (PKI) that uses an instance of InterSystems IRIS as a CA, allows you to create key pairs, and allows you to create certificates that are associated with these key pairs. The InterSystems CA is suitable for use within organizations internally and in non-production environments. It is not recommended for use as a production or commercial CA; while its certificates are cryptographically sound, a commercial CA requires a level of organizational and legal infrastructure in additional to technological infrastructure. Public-key cryptography with a PKI supports a number of vital secure activities:
The Fundamentals of How Public-Key Cryptography and Certificate Authorities (CA) Work TogetherWhen using public-key cryptography, each entity has a private key, which is a closely held secret, and a public key, which is made widely available. If you perform an action with one key, you can perform the complementary action with the other key; for example, if you encrypt data with your private key, then only your public key can decrypt that data. If someone else encrypts content with your public key, only your private key – and therefore, only you – will be able to decrypt it. This means that public-key cryptography provides a means for secure and private communications between two entities. For public-key cryptography to be useful among entities who do not know each other and who cannot easily verify each other’s identity, there needs to be a third party that both entities trust. This third party is the certificate authority (CA). Certificate authorities create certificates, which are digital documents that bind a public key to a set of identifying information for the public key’s holder. Since the public key and the private key are inextricably tied to each other, a certificate also binds the identifying information to the private key. Some organizations have in-house CAs, which they use to support internal activities; other CAs operate as independent organizations, usually providing certificates as a commercial service. Commercial CAs typically offer certificates based on varying degrees of identity verification; with sufficient verification, a certificate can create a legally binding tie between an organization or person and a public-private key pair. The use of CAs allows entities in an unsecured environment to have sufficient confidence to use public-key cryptography in meaningful and legally binding ways. Entities that are communicating with each other do not need to use the same CA. Rather, each one simply needs to trust the other’s CA. This relationship of trusting a CA is usually established without any user intervention, such as by having a browser ship with a set of pre-approved CA certificates. In fact, an entity can trust one CA because it has a certificate from a second CA that is already trusted; in this scenario, the first CA is known as an intermediate CA — and there can be multiple intermediate CAs. When an entity obtains a certificate from a CA, a number of events have occurred – frequently without being visible to the user. First, the CA client uses an algorithm to generate the key pair; the CA client then obtains necessary information to describe the entity using the key pair, which has to do with the entity’s location, organization, and so on. Taken all together, this identifying information comprises a distinguished name (DN). The entity provides the public key and DN information to the CA in the form of a certificate signing request (CSR); it does not provide the private key because, again, this is a closely held secret. The CA receives the CSR and then processes it according to its procedures. The CA then signs a document that binds the public key to the DN information, thereby creating a certificate (specifically, a certificate that conforms to X.509Opens in a new tab standard). Finally, the CA client obtains the certificate from the CA, and then can use it for various activities, such as establishing a TLS connection. When two entities need to authenticate each other, they use their certificates and the CA’s trusted relationship to them. Hence, when Alice and Bob attempt to communicate via, say, TLS, the TLS handshake performs authentication for each of them as follows:
About the InterSystems PKITaken all together, the activities of a CA and of public-key cryptography are part of what is called a public key infrastructure (PKI). Hence, a PKI provides a means of creating and managing key pairs and certificates, and can support cryptographic operations including encryption, decryption, and digital signing and signature verification. InterSystems IRIS includes a PKI. With the InterSystems PKI, you can set up a Certificate Authority (CA), a CA client, and start sending secured data between users in a matter of steps. When an instance of InterSystems IRIS is acting as a CA, it is known as a CA server; when an instance is using a CA’s services, it is known as a CA client. A single instance can be both a CA server and a CA client. When establishing itself as a CA server, an instance of InterSystems IRIS either creates a key pair and then embeds the public key in a self-signed X.509 certificate or it uses a private key and X.509 certificate signed by an outside CA. X.509 is an industry-standard certificate structure that associates a public key with a Distinguished Name (DN). Trying the InterSystems PKI for YourselfIt’s easy to set up and use the InterSystems PKI. In this example, you will use two instances of InterSystems IRIS. You are going to perform a series of initial operations with instance #1 as a CA (here primarily known as a CA server) and instance #2 as a CA client. The steps are:
Important: The InterSystems PKI is not for use on production systems. Further, the example in this First Look simplifies the process of setting up and using a CA in ways that are not appropriate for a production system that uses any PKI. For example, it provides a suggested password that is used to encrypt and decrypt the CA server’s private key. On a production system (or anything other than a demo system such as this one), never use a publicly known password, as this could jeopardize the security of your CA’s private key and therefore your entire PKI; if this key is exposed or compromised, then all of a CA’s certificates become untrustworthy. Similarly, the directory for Certificate Authority’s certificate and private key files is on the same machine as the instance of InterSystems IRIS that you used for this First Look’s exercises. For a production system, this directory should always be on an external device (not a local hard drive or a network server), preferably on an encrypted external device. This is because the directory holds the private key of the CA. If you create a production system, follow the instructions from your PKI vendor. For more details about using the InterSystems PKI for development or test systems, see The InterSystems Public Key Infrastructure. Before You BeginTo use this procedure, you will need two running instance of InterSystems IRIS. These instances can be on the same or different hosts, but must have network access to each other. Your choices for InterSystems IRIS include several types of licensed and free evaluation instances; the instance need not be hosted by the system you are working on (although they must have network access to each other). For information on how to deploy each type of instance if you do not already have one to work with, see Deploying InterSystems IRISOpens in a new tab in InterSystems IRIS Basics: Connecting an IDE. Configure Instance #1 as a CA ServerTo configure instance #1 as a CA server:
Configure Instance #2 as a CA ClientTo configure instance #2 as a CA client:
InterSystems IRIS acknowledges success through a message such as “Certificate Authority client successfully configured.” On Instance #2, Submit a Certificate Signing Request (CSR) to the CA ServerNext, on instance #2, submit a certificate signing request (CSR) to the CA server:
On Instance #1, Process the CSROn instance #1 (the CA server), process the CSR, which turns it into a certificate:
InterSystems IRIS has now created the certificate. If the CA client has an email address listed for its technical contact, that address also receives notification that the certificate is available for download. On Instance #2, Download Its Certificate and CA Server Certificate from the CA ServerThe next and final step is for the CA client to download from the CA server both the CA server’s certificate and its own certificate:
Wrapping Up and Next StepsYou have now:
This means that you now have one InterSystems IRIS instance that is a functioning CA server and another InterSystems IRIS instance that is a functioning CA client. If you set up a CA client on another InterSystems IRIS instance and create TLS configurations for each instance, the two clients can exchange encrypted messages. This provides the basis for various secured activities. Caution: A final reminder: this example system does not help establish a secure environment because the CA’s private key has been publicly published in this document. It is critical that you properly protect all private keys in production systems, and it is most important that you protect the private key of a CA. The exposure of a private key for use in a production system can result in security breaches, data exposure, financial losses, and legal vulnerability. Do not use this document’s CA server private key for anything other than educating yourself about InterSystems IRIS features. Learn More About the InterSystems PKIFor full documentation on the InterSystems PKI, see The InterSystems Public Key Infrastructure. What is a Certificate Authority CA quizlet?What is a certificate authority? - An entity that requires proof of identity from the individual requesting a certificate. - An entity that generates a digitally signed identification certificate.
Which of the following entity in the certificate authority CA hierarchy validates the certificate request from a client?When a client requests a certificate, Registration Authority (RA) validates the request. If the validation is successful, then the RA confirms to the CA that a certificate can be issued based on the client's request.
What is the purpose of a server certificate quizlet?What is the purpose of a server certificate? Guarantee the identity of e-commerce sites and other websites that gather and store confidential information.
What information is included in a digital certificate?Digital certificates include the public key being certified, identifying information about the entity that owns the public key, metadata relating to the digital certificate and a digital signature of the public key the certificate issuer created.
|
Which certificate field shows the name of the certificate authority CA expressed as a distinguished name DN )?
zusammenhängende Posts
Urheberrechte © © 2024 paraquee Inc.
