Advantages of modular PKI for implementation in information systems

Transcription

1 Advantages of modular PKI for implementation in information systems Petr Vaněk, Jiří Mrnuštík AEC spol. s r.o. Bayerova 799/ Brno, Czech Republic Abstract PKI implementation in practice is not limited only to technical and organizational construction of a trustworthy authority that issues certificates. The Certification Authority establishment includes many partial systems such as signing units, certificates and requests storage and CRL management. Certification and CRL publications require constructed FrontEnds such as WWW, LDAP, OCSP and others. No less important part of Certification Authority are Registration Authorities. The establishment of CA and RA itself is only one of the targets that are awaiting for the person responsible for the implementation. There are many applications that use PKI infrastructure. This contribution is first of all focused on electronic signature matter and on data security used not only during communication via electronic mail. Together with electronically signed documents we are also speaking about Time Stamp Authority and services related to TSA. The supplied solutions have often the disadvantage of its finality and the impossibility to use the constructed PKI in other information systems. Many information systems implemented in practice need to resolve the incorporation of PKI by the easiest way possible. This is way the author points at advantages of PKI with modular structure and open interfaces constructed on AEC PKI SDK. The suitable combination and connection of boxed products and the existing information systems by SDK helps not only to save finances but also to shorten the development circle. 1 We start from the end The encryption and electronic signature is becoming inevitable part of each information system that handles in any way some sensitive data. For apprehension let s start with the need to secure message sending between two participants. For various purposes the symmetric cipher with the key generated from password will be sufficient but the necessity to share this secret and distribute it to the individual participants leads us to the use of the asymmetric cipher. Broadly spread and used communication system is electronic mail ( ). The most frequently used security protocols of today are PGP and S/MIME. In recent times the S/MIME protocol is supported more and more. It is implemented very often to the client programs working with their electronic mail. To enable an understandable between participants, it is necessary to state a communication protocol (data formatting). The base is standard PKCS#7 (RFC 2315) that is today replaced by CMS (Cryptographic Message Standard, RFC 2630). The types of the most important data contents according CMS are summarized in table 1. Security and Protection of Information

2 Data type OID (object identifier) Significance Data Content Type id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } The data itself, e.g. signed,.. SignedData Type id-signeddata OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } Electronically signed data EnvelopedData Type Digested-data Content Type Encrypted-data Content Type AuthenticatedData Type id-envelopeddata OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } id-digesteddata OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } id-encrypteddata OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } id-ct-authdata OBJECT IDENTIFIER ::= { iso(1) memberbody(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 } Tab. 1 Encrypted data (data in envelope) Data with imprint (HASH) Data encryption, does not include information about cipher-key Authentication, if electronic signature can not be used 1.1 Electronically signed data what to do with it? As indicated above, the data type used for electronic signature is id-signeddata. We will not enter into details of CMS but let s have a look briefly at the electronic signature structure. SignedData ::= SEQUENCE { version CMSVersion, digestalgorithms DigestAlgorithmIdentifiers, encapcontentinfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT CertificateRevocationLists OPTIONAL, signerinfos SignerInfos } where SignerInfos ::= SET OF SignerInfo and next then SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestalgorithm DigestAlgorithmIdentifier, signedattrs [0] IMPLICIT SignedAttributes OPTIONAL, signaturealgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedattrs [1] IMPLICIT UnsignedAttributes OPTIONAL } The message id-signeddata is composed of several items such as version, sets of algorithm identifiers for calculation of message imprint, encapcontentinfo, certificate, CRL and information about the subscribers. The item EncapsulatedContentInfo defines the sequence of data type and of the signed data itself. These are not, however, the obligatory content, see for example extra signature. The set CertificateSet may contain certificates related to subscribers, eventually with a full scope path to CA. In the same way even the currently enclosed CRL can be included in CertificateRevocationLists. From the description of id-signeddata is visible that we can add arbitrary number of signature sequences (SignerInfo) related to signed data (EncapsulatedContentInfo). The data are not always included - in that case we speak about so called extra signature. For distribution of certificates with complete path to the root authority is used wrapping into this sequence in a way that the data part EncapsulatedContentInfo is again empty and SignerInfos is also an empty set. This data type has usually file extension p7c or p7b. Sequence SignerInfo contains apart from the signature itself and algorithm identifiers also signed/not-signed attributes. Among the most important signed attributes are message imprint, type of signed data and time of signature. As we will see later, the finally mentioned attribute is not very trustful. In summary we can say that data type id-signeddata has the following purposes: 192 Security and Protection of Information 2003

3 compact format for signature (signatures) and data itself separated signature (extra signature), where the data are stored separately certificate and/or CRL wrapping either separately or with signatures 1.2 Data encryption, data in electronic envelope Why do we say electronic envelope? Electronic enveloped id-envelopeddata of the message is created by the following way: EnvelopedData ::= SEQUENCE { version CMSVersion, originatorinfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientinfos RecipientInfos, encryptedcontentinfo EncryptedContentInfo, unprotectedattrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } where RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo RecipientInfo ::= SEQUENCE { version Version, issuerandserialnumber IssuerAndSerialNumber, keyencryptionalgorithm KeyEncryptionAlgorithmIdentifier, encryptedkey EncryptedKey } The message is encrypted by a symmetric cipher where the key is generated randomly and this key is then encrypted by a public key (certificate) of the recipient. Each recipient has his own structure RecipientInfo. The above stated structure RecipientInfo is valid only for case PKCS#7 where the version is equal 0. The recipient identification (of certificate) is done from the serial number of certificate and from the unique name of CA (issuerandserialnumber). CMS brings a possibility of another identification with help of SubjectKeyIdentifier (version 2). Other versions 3 and 4 are not very widespread. 1.3 From CMS to S/MIME CMS messages are in binary form and are suitable for native signature and/or data encryption. Format S/MIME was introduced because of the electronic mail requirements. The format supports from CMS only: iddata, id-signeddata and id-envelopeddata. S/MIME defines the way of CMS messages packing to the MIME form; it means it performs BASE64 coding and the relevant MIME headers are added. From: "Petr Vanek" <bpdevelopment@seznam.cz> To: "JK" <jkrcal@atlas.cz> Subject: Report Date: Fri, 7 Feb :57: MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; boundary="----=_nextpart_000_0005_01c2ce8f.59eacb00"; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" MIAGCSqGSIb3DQEHA6CAMIACAQAxggI1MIHYAgEAMEEwNTEWMBQGA1UEAxMNTXlDQSBmb3IgbWFp. 1.4 Do we really need S/MIME? Here we thing about necessity of wrapping of CMS messages into S/MIME format. We carry out only BASE64 encoding, it means a transfer into 7. bit representation and we add description information so as the mail clients are able to process the information. For storage and work in information systems it is not absolutely necessary to convert CMS into S/MIME format. This transformation only extends the data volume and slows down the manipulation. A frequently discussed question is data signing in database. To sign all data stored in database is ineffective from the point of overloading of equipment power during creation and verification of signature and also from the point Security and Protection of Information

4 of the way of signature creation by the private key owner. The transparent signature procedure means that DB engine or signing front-end data proxy signs anything that is on the entrance. The private key participated in signature must be permanently unlocked, so we have used the signature only to ensure the integrity of data in the database. To sign records has the sense only in case where there is a concrete person behind these records, eventually service that signs by its private key. Whereas the key is unlocked only for the shortest time possible, only for creation of the signature. In case of signing of large amount of data (columns etc.) it is possible to sign the final data processing (summary report); this report can be placed in an archive. In case where it is not possible to process the summary report, there can be defined rules by application logic for definition of an extract from individual records and a extra signature is created. The extra signature may be stored separately into the database column. There are several solutions how to simply apply signing, and eventually encryption functions. Usually there are separated libraries of crypto core and ASN processors where the programmer himself must compile the individual parts of the message. This is too complicated way for IS (Information System) implementers and this technology has many way of solutions. From the programmer point of view it is ideal to carry out as few steps as possible (function calls) to achieve the success. That is way various SDK (Software Development Kit) are developed. They provide sufficient set of functions for full-scale work with electronic signature and/or encryption. We are often implementing only a narrow set of functions e.g. creation and verification of electronic signature but we would be losing precious time during the construction of the whole functional infrastructure with help of random SDK. The necessary supplementary applications (such as key pairs and CRL management, key generators, LDAP storage etc.) are repeated every time. It seems that the ideal answer is the boxed solution where it is possible to complete functionality by necessary IS modules so as we get a compact entity. There are few suppliers that are willing to provide SDK and to enable connection to the existing applications of product portfolio. 2 Key pairs We can use the above-mentioned signing providing that we own a key pair; it means a private key and a public key certification. The key pair is generated by a generator that calculates the pair with help of some of asymmetric algorithms. Let me remind that for key generating we do not need only the algorithm but also the length of the generated key. Not all SDK or applications are capable to accept arbitrary algorithm. We consider RSA as the implemented standard. A serious competitor regarding the rapidity and the key size are algorithms based on elliptic curves. Table 2. shows the outline of asymmetric algorithms and key sizes that should be supported by all up-to-date PKI solutions. Name Key length in bits RSA Diffie-Hellman modulus 1024, private key 160 DSA 1024 Elliptic Curves 112, 160, 180, 192, 256 Tab 2. Before the key pair generating it is advisable to have the possibility to initialize explicitly the generator of random numbers to ensure the greatest security possible (non-deductibility of the key from the ascendant). SDK must shield another no less important task and it is the protection of the private against eventual exploitation. The generating of private keys in save memory and its following encrypted storage on disk will be sufficient for various purposes. By the safe memory we mean here a memory space that is with help of kernel driver guarded against memory swapping to disc. Before unblocking of this place the key is overwritten by defined formula in a way that the key itself does not appear in any other place. Because there exist techniques how to acquire this key, e.g. during system hibernation when the whole operation memory is stored on disc (done by OS) or by another kernel driver searching in operational memory for keys, there must exist safer storage. The storage can be smart card, tokens that apart from memory chip carry in them microprocessor that includes its own OS with crypto core. Thanks to this OS we are able to generate the key pair inside of the token so as the private key never leaves the token. The definition never leaves is meant it the sense that the firmware producer for token binds itself to it. But the possibility of back door always exists. The impossibility for the private key to leave the token may be a disadvantage; it is the case when we need to backup our private key from some reason. 194 Security and Protection of Information 2003

5 The common tokens do not have this option. CA requires this option inevitably. There exist equipment such as Chrysalis ITS Luna CA3 that contains the required utility. This equipment is certified to the standard FIPS-141 level 3 so we can trust that copying can not be used as a backdoor. In case of CA where the investment would exceed tolerable boundary because of this equipment, it is possible to generate the key pairs in safe memory, then import them into tokens and delete these keys from the memory. In case of token use the keys are protected by application logic of given firmware and the access is ensured by one or more PINs. With keys stored on common memory media the most passable way is PKCS#12 format. These keys are then protected by access password from which is extracted the encryption key for private key protection. P12, as this format is called for short, is suitable even for storage of private keys including their certificates. Efficiently designed SDK should wipe away the differences among the use of individual storages. 3 Certificates The public keys obviously belong together with private keys. The public keys by themselves do not carry any owner identification. We verify the public key to be secured against forgery. The certificate is a data structure that contains, apart from public key, other description information about the owner, issuer, the purpose and so on. Leaving aside the special case where the subscriber is the owner (selfsigned), the issuer should provide sufficient guarantee for the data stated in the certificate. The issuer is called Certification Authority. To issue a certificate by CA it is necessary to have a request that must be put together by the applicant during key pair generating, it means private and public keys. There are several standards related to the request format. The most expanded is PKCS#10 format that is described in RFC The request itself is similar to a simplified certificate signed by applicant s private key. CertificationRequest ::= SEQUENCE { certificationrequestinfo CertificationRequestInfo, signaturealgorithm SignatureAlgorithmIdentifier, signature Signature } CertificationRequestInfo ::= SEQUENCE { version Version, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, attributes [0] IMPLICIT Attributes } The content is signed (Signature), CA then verifies this signature and by this also the fact that the applicant owns his own private key. SubjectPublicKeyInfo carrying the information about the applicant public key and its algorithm are the most important information contained in the request for certificate creation. Information in item subject that should carry a unique name is rather a recommendation of the content for the issuer, for CA. There will be many people that will not agree with this statement but let s have a look at this problem in practice. The user or if you like his client s software may not be always able to produce a request with the appropriate extensions and can not know his unique name in the CA frame. That is way the RA officers complete the information in accordance with the executive rules of CA and place them on the unique name in the CA frame. Certificate ::= SEQUENCE { tbscertificate TBSCertificate, signaturealgorithm AlgorithmIdentifier, signaturevalue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialnumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectpublickeyinfo SubjectPublicKeyInfo, issueruniqueid [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3 subjectuniqueid [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version shall be v3 } Security and Protection of Information

6 The certificate itself is a structure (see above) that may, due to possible extensions in version X509 v.3 cause numerous problems with handling and data representation. The certificate is constantly developing. PKI SDK should be at least able of partition and presentation of unknown extensions. We should not also forget the work with qualified certificates according RFC As we can see, the objects (keys, certificates,...) in PKI have a very complicated structure. Many PKI SDK uses complicated structures, eventually leaves up to the user himself to set up the structures. With this approach the implementation is burdened by a high error rate and it places great requirements on programmers knowledge. The whole problem can be also seen from a different angle. PKI SDK should be also seen from the user point of view, not only from the point of view of rules and recommendations although these must be accepted internally. If we complete such a system by the option of universal data representation as XML is, we have good suppositions of open system base. 4 Certification Authority Certification Authority (CA) stands on the top of the whole PKI trustworthiness. It is not obligatory to implement in the frame of PKI to IS own CA. In case of small IS it is possible to use commercially accessible CA of third parts. For closed and independent solution is nevertheless convenient own CA construction. CA is not only signing equipment that signs the certificate requests but complex program and organizational background. The CA construction can be approach by different ways. One of them is the CA construction on base of PKI SDK; but this way we acquire only signing equipment. Another alternative is getting of application components such as signing equipment, RA, storage management, LDAP and others. Apart from Ca components itself it is necessary to create documentation base, executive rules, and other documents needed for smooth course of CA. CA should publish its certificates. Most of CAs limits to the option to provide the certificates through web interface. This approach may have disadvantages during implementations IS where it is necessary to procure certification according various criteria. As alternative distribution channels are used directory servers, usually LDAP. The certifications can be revoked during the validity from various reasons. CA creates lists of revoked certificates and places them into signed lists called CRL (Certificate Revocation List). The way of revoke request is solved in CA certification policy. These CRL CA generates in prescribed time intervals and issues them on so called distribution places, usually defined with help of URL. These distribution places are also stated in issued certificates so as the user have always the possibility to verify the certificate. Here we encounter the biggest problems with implementations. It is not always the best solution to copy CRL from CA and check with the certificate. The whole process is greatly slowed down and it leads almost to system malfunction. Let s have a look at the following example of IIS where it always copies CRL during the use of SSL and check of client s certificate. To ensure IIS function it is necessary to switch off this. An alternative method may be the application of individual crl on certificates in storage and their deposit in local PKI. Here it is necessary to carry out copying and application CRL in storage (check of certificate in storage already included) in intervals defined by CA. OCSP protocol for detection of given certification state tries to solve this problem. But this one has also its drawbacks. During the check of signed document signature, we will monitor several certificates CA, TSA and client s. In the course of common work with certificates the frequency of network connections to OCSP will be rather high. 5 Time Stamp One of the signed attributes in electronic signature is time. As was already mentioned this attribute is not very trustful because the time stated in this attribute is not guaranteed by anybody. The data in this attribute can not be disproved nor verified without use of additional utility. When we check the electronic signature, we need to be sure that the signature was created in time when the certificate of signing party was valid. The certification is valid if its time validity has not passed and if it was not revoked by the CA that issued it. The time of signature belong among the signed attributes and therefore it can not be modified or completed by any signed attributes. The possibility how to add trustful time to the existing signature is the use of non-signed attributes of signature as it is stated in RFC 3126, it means addition of time mark token. OID of non-signed attribute of own signature is defined as id-aa-signaturetimestamptoken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 196 Security and Protection of Information 2003

7 The content itself is then SignatureTimeStampToken, which is signed message id-signeddata according to CMS. The signed data have then the following structure TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageimprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialnumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. gentime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL } The item messageimprint contains signature imprint and we add time stamp token to it. The item gentime defines the time when the time stamp was created. The issue of time stamps is controlled by certain policy similarly to certificates. The definition of policy is done by the item Policy. The institution that issues the time stamps is called Time Stamp Authority (TSA). The communication with TSA can be done by several methods. Transport protocol http appears to be universal either because of its widespread usage by various clients libraries or because of its passage through firewall. The electronic signature is not the only application of time stamp but it can practically be created for arbitrary imprint. The imprint can be done from a document, a log or other files where we wish to prove their existence in time. 6 Summary of requirements for modular PKI and SDK This article presented a very simplified cross-section by surrounding of electronic signature and encryption in IS. As we can see, there are many requirements for PKI system functionality. Because the PKI is being constantly developed, the individual modules, libraries and SDK must be designed so as the system does not disintegrate by eventual changes. The openness and modularity from the point of applications as well as PKI itself are necessary conditions for successful implementation into IS. Security and Protection of Information