Digital certificates containing multimedia data extensions5712914Abstract A method and apparatus of communicating information comprising providing a datum which includes a digital certificate containing data. The digital certificate including an extension which includes: a first identifier which specifies a major classification of the data; a second identifier which specifies a minor classification of the data; and data in a format according to the major classification and the minor classification, the data indicating an owner of the datum and a use for which the datum is intended. The certificate allows authentication of the certificate itself and the data contained therein, and the data contained in the certificate can include information allowing verification of the identity of the holder of the certificate. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Extensions ::= SEQUENCE OF Extension
Extensions ::= SEQUENCE
extnId EXTENSION.&Id({Extension}),
critical BOOLEAN DEFAULT FALSE,
extn Value OCTET STRING // DER encoding of data
value
}
EXTENSION ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&ExtnType
}
WITH SYNTAX
{
SYNTAX &ExtnType
IDENTIFIED BY & Id
}
______________________________________
IDENTIFICATION EXTENSIONS The following identification extensions are non-critical extensions. Logo Extension The logo extension defines a bitmap image which is used for brand identification. One example of the use of this extension would be for a credit card company such as VISA or MasterCard, to have their logo stored in this extension for display when the certificate is displayed. It has the following syntax:
______________________________________
logo EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id-ce 30 }
}
Image Syntax ::= SEQUENCE
{
algorithm AlgorithmIdentifier, // type of image
imageData ImageData // binary data for image
}
______________________________________
Signature Extension The signature extension represents a binary-encoded facsimile of a handwritten signature. It may be a scanned copy of a written signature, or the signature may be made on a much sensitive-pad and encoded directly. Regardless, the purpose of this extension is to display the signature in a certificate and compare it with a hand-written signature to verify identity. The syntax uses the same image data as the logo extension as follows:
______________________________________
signature EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id-cc 31 }
}
______________________________________
Picture Extension This extension is meant to contain a picture of the owner of the certificate. It consists of a bitmap image in some standard format. It could be used for a picture of an owner of a certificate for an identification or credit card certificate. It is constructed in the same fashion as the logo and signature extensions:
______________________________________
picture EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id-ce 32 }
}
______________________________________
Sound Extension This extension will allow a certificate to contain an audio clip. It may be used for identification of the owner's voice. It contains an audio clip (e.g..WAV) in some standard binary format. The format for this extension is as follows:
______________________________________
audio EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id-ce 33 }
}
AudioSyntax ::= SEQUENCE
{
algorithm AlgorithmIdentifier, // type of image
audioData AudioData // binary data for sound clip
}
AudioData ::= OCTET STRING
______________________________________
Video Extension This extension will allow a certificate to contain a video clip. It may be used for identification of the owners appearance or other information which needs to be stated by the owner. It contains a video clip in some standard binary format. The format for this extension is as follows:
______________________________________
video EXTENSION ::=
SYNTAX VideoSyntax
IDENTIFIED BY { id-ce 34 }
}
VideoSyntax ::= SEQUENCE
{
algorithm AlgorithmIdentifier, //type of clip
videoData VideoData //binary data for video clip
}
VideoData ::= OCTET STRING
______________________________________
If a certificate contains both an audio and video extension, they are assumed to be synchronized in time; that is, the algorithms used to create both of them must be able to be synchronized if both the audio and video are started at the same time. Biometric Extensions This extension can represent some biometric input which is used for identification purposes. The goal of these formats is to verify that the user of the certificate is really who they say they are. The data stored with the certificate would be compared with that input via some biometric device to validate the user's identity. One possible use of this extension is in security access cards where the user of the card must validate themselves in order to gain entry into high-security building or room. Biometric devices come in several forms, each of which represents data in one or more different binary formats. Following is a list of the more popular biometric formats and the type of extension(s) they require. An important consideration regarding biometric devices is that the input data from the user can change over time. That is, a person's fingerprint, hand print, or voice can change over time, eventually rendering the certificate invalid. Fingerprint Fingerprints are stored in one of three different formats: Image, language, and index plot. Image format is simply a bitmap image which must be visually compared to that stored in a certificate. This data will be stored in the following extension:
______________________________________
fingerprintImage EXTENSION ::=
SYNTAX ImageSyntax
INDENTIFIED BY { id-ce 35 }
}
______________________________________
The language format is an ASCII representation of the fingerprint after filtering the fingerprint image. This value can then be compared to that stored in the certificate. This data will be stored in the following extension format:
______________________________________
fingerprintLanguage EXTENSION ::=
SYNTAX FingerPrintLanguageSyntax
IDENTIFIED BY { id=ce 36 }
}
FingerPrintLanguageSyntax ::= IA5String
______________________________________
The last format for storage of fingerprints is via an index plot of the fingerprint. This plot is also a bitmap representing the print, but only is concerned about certain aspects inherent in the print. This extension is also stored as an image:
______________________________________
fingerprintIndexPlot EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id=ce 37 }
}
______________________________________
Retina Scan Retina scans create a bit vector representing the location of blood vessels in the retina of the eye. This relatively short vector generated by a scanning device can be compared to that stored in a certificate for identification purposes. Since the result is simply a bitmap, the following extension syntax is used:
______________________________________
retinaScan EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id=ce 38 }
}
______________________________________
Voice Print Voice prints are usually stored as audio files and are processed to compare two samples. Thus the audio extension format will be used:
______________________________________
voicePrint EXTENSION ::=
SYNTAX AudioSyntax
IDENTIFIED BY { id=ce 39 }
}
______________________________________
Hand Geometry Geometry of the hand is usually stored in an image format. The following extension is defined:
______________________________________
handGeometry EXTENSION ::=
SYNTAX ImageSyntax
IDENTIFIED BY { id=ce 40 }
}
______________________________________
Dynamic Signature Dynamic Signature data is stored as accelerations sampled during the actual writing of user's signature. This data will be sorted in some binary format for later comparison with that received from the biometric device. It is unclear what exact format this data will take. MISCELLANEOUS EXTENSIONS Account Number Extension This extension is used to store an account number in a certificate. It may not always be possible to use the serial number to store the account number in the case of revocation and later reinstatement, where the same account number would be used. Hence the serial number cannot be use in this case as serial numbers must be globally unique. The syntax for this extension is as follows:
______________________________________
accountNumber EXTENSION ::=
SYNTAX AccountNumberSyntax
IDENTIFIED BY { id=ce 41 }
}
Account Number Syntax ::= INTEGER
______________________________________
Executable Code Extension This extension is reserved for use by applications to execute trusted code contained in the certificate. The extension is simply a sequence of bytes which will be interpreted by the application as an executable. The format is as follows:
______________________________________
executableCode EXTENSION ::=
SYNTAX ExecutableCodeSyntax
IDENTIFIED BY { id=ce 41 }
}
ExecutableCodeSyntax ::= OCTET STRING
______________________________________
TEMPLATE EXTENSIONS A template extension is used to determine which template the certificate follows, that is, which extensions are to be found in the extensions field in a certificate. This extension is located at a well-known place in the extension list (e.g. the first extension) and gives insight into what the certificate is used for and perhaps how to display the certificate to the user. The template types are discussed in detail below. The syntax for this extension is as follows:
______________________________________
templateExtension EXTENSION ::=
SYNTAX TemplateSyntax
IDENTIFIED BY { id=ce 41 }
}
Template Syntax ::= SEQUENCE
{
major INTEGER, // major number of template
minor INTEGER // template minor number
______________________________________
An illustration of a template extension 600 is shown in FIG. 6. A template identifier field 602 contains a unique value identifying the extension as a template extension. The template extension is critical, that is, if the application cannot interpret the template, it cannot use the certificate for any purpose other than as a template for the purposes specified in the major and minor type fields 606 and 608. The criticality flag in field 604 is set by default to "yes", however, it may be set to "no" in some implementations. The template identifier determines which template (if any) the certificate follows. The template extension is made up of a major and minor type specified in fields 606 and 608. The major type contained in field 606 represents the basic use of the certificate, for example, whether it is used for identification or a credit card. The minor type contained in field 608 represents the exact type of data the certificate stores. For example, a certificate could have the major type of identification and the minor type of driver's license. The major type specifies a certain set of required multimedia extensions (either implicity or explicitly through some undefined mechanism) which must be used to verify the holder of the certificate. Verification of the holder of the certificate can be performed using any of the multimedia extensions set forth above. The template extension is placed in a well-defined place in the certificate, in this embodiment, as the first extension in the extensions portion of the extended X.509 certificate. Implicitly, the major and minor type specify the number and types of fields which follow in the extension, and each extension includes an identifier which identifies the specific extension. Thus, required major multimedia extensions 610 follows the specification of the minor type, and required minor multimedia extensions 612 follows the required major multimedia extensions 608. Required major multimedia extensions 610 include data common to all certificates of the major type, and required minor multimedia extensions include data specific to the specified minor type. Lastly, format 600 includes an "other extensions" field 614 which are other extensions used in the certificate which are not of the required major or minor types. Following is a list of defined major and minor template types in implemented embodiments of the present invention and a description of each. IDENTIFICATION TEMPLATE TYPE This major type of template includes one or more of the identification certificate extensions defined above. This class of template includes the minor types of applications as set forth in Table 1.
TABLE I
______________________________________
Minor Type Extensions and Other Data Required
______________________________________
driver's license
state logo, picture, birth date, height,
weight, sex, restrictions, license
number
birth certificate
hospital logo, parents' names, birth
date, hospital name, footprint
social security card
SS logo, SS number
library card library logo, account number
frequent flier card
airline logo, account number, signature
of user
passport country logo, picture
corporate id badge
corporate logo, id number, picture,
audio, video
building access card
logo
medical insurance or
logo, account/group number
prescription card
______________________________________
As is apparent in the above-examples, the common clement for each of the identification extensions is the logo of the issuing authority. Thus, required major multimedia extensions for such an extended certificate would include the logo in the required major multimedia extensions field. An example of an identification template is shown as 700 in FIG. 7. This data will be contained in the extension data field 506 of a template extension. Each of the data fields will have an associated identifier and criticality flag, as set forth above. In this embodiment, the major type contained in field 702 will identify the template as type identification. The minor type, in this instance, contained in field 704, will identify the template as being of type "California driver's license." Thus, the basic use of the template is identification, and the specific instance of identification is a California driver's license. A logo (the logo of the state--the issuing authority) follows in field 706, for the required major multimedia extensions of this identification template. Subsequent fields in the certificate, in this example, arc required minor multimedia extensions. These include: a image of the licensed driver in field 708; a birth date of the driver in field 710; height, weight and sex of the driver in fields 712, 714, and 716; license restrictions contained in field 718; and a license number in field 720. Thus, when authentication of the certificate takes place, the hash function is performed not only on the unextended portion X.509 portion of the certificate, but also, on extended data 700 shown in FIG. 7. A certificate thus contains data such as 700 which not only provides stronger (perhaps visual or other manual) authentication of the holder of the certificate, but also, provides a container for data which is self-authenticating. That is, it not only allows access checking of directories and associated directory services, but also, provides stand-alone features not connected with any such prior art techniques. A second example of an identification template is shown as 800 in FIG. 8. This extension will be contained in the extension data field 506 of a template extension. The minor type, in this example, contained in field 804, will identify the template as being of type "Birth Certificate." The hospital logo follows in field 806, for the required major multimedia extensions of this identification certificate. The following fields in the extension field are for required minor multimedia extensions. These include: the parent's names in field 808; a birth date of the child in field 810; the hospital name in field 812; a image of the footprint of the infant in field 814; and a signature of the doctor in field 816. Credit Card Template Type This type of certificate template includes some identification portions as well as storage for the credit card number itself. An example of this is illustrated as 900 in FIG. 9. The major type specified in field 902 is credit card, and the minor type contained in field 904, in this example, is "Citibank Visa." Fields 906-912 comprise the required major multimedia extensions fields and specify the credit card number, an image of the user's signature, the issuer's name, and the issuer's logo. The issuer's logo preserves the brand identity associated with the credit card (e.g. Citibank Visa). Other information may also be associated with the certificate, such as credit limit, etc. . . . according to implementation. Minor fields may include those as illustrated in fields 914-920, such as a user's photo, user's password (for stronger authentication), a "member since" field, and an image of the card itself. In alternative implementations, it may also contain a picture of the user and an audio or video clip. THE CERTIFICATE APPLICATION A flow of a process of a certificate application 110, which is resident in computer memory during system runtime in a transaction system (e.g. a point-of-sale system), is illustrated in FIG. 10. The certificate is read at step 1002. This may be performed in any number of manners, including, but not limited to, receipt of the certificate over a communication link, reading of the certificate off magnetic media on a credit/identification card, etc. . . . Authentication of the certificate is then performed at step 1004. This is performed using the specified hash algorithm of the data in the certificate, decryption technique using the public key of the issuer, and comparing the result against the supplied signature. If the certificate is not authentic, as detected at step 1006, then process 110 proceeds to step 1007, wherein a user may be alerted and the process aborts. If the certificate is authentic, then process 110 proceeds to step 1008, wherein the extension type is checked. If the examined extension type is not understood by the application program, then the criticality flag is checked at step 1014. If the extension is critical, then the use of the certificate is aborted at step 1018, and the user can be alerted at step 1007, wherein the process ends. If the certificate extension is not critical (e.g. a template extension) then the certificate can be used, if desired by the application, without the extension(s), if any at step 1016. If the extension is understood by the application, as detected at step 1010, then it can be used at step 1012 with the extension(s). In either event, the process then is complete. In the event of an extension type which is one of the simple multimedia data types illustrated and discussed above, the application simply checks the type and determines whether it is supported, and if so, can use the extension. If not, the DER length field can be examined, and the extension field(s) can be skipped over, and not used by the application, according to implementation. In the event of a template type, both the major and minor types can be examined, and if either or both are supported and required by the application, it can be used. The details of this are shown in FIG. 11. Process 1100 shows the details of checking a template's major and minor type. First, at step 1102, the major type is checked. If it is not supported by this application, as detected at step 1104, then, at step 1106, it can be indicated that the certificate is not understood, and the process is complete. If the major type is understood by the application (e.g. an identification type), then it is determined whether the minor type is required at step 1108. For example, for a simple identification procedure with authentication, the validity of the certificate may simply be required to be checked. This would be similar to the standard X.509 authentication procedure. If not, then it the certificate is indicated as understood at step 1110, and the process is complete. Step 1112 checks the minor type in the event that the minor type is required. If understood, as detected at step 1114, then the certificate is indicated as being understood at step 1118, and the process is complete. If not, then the certificate is indicated as not being understood at step 1116, and the process is complete. FIGS. 12 and 13 illustrate examples of the use of digital certificates with multimedia extensions, as set forth at steps 1012 and 1016. These examples illustrate the processes which may be performed for the checking of the validity of a driver's license, and a credit card for the performance of a transaction, respectively. Process 1200 may be an identification process used with a driver's license, for example. Once authentication of the license via examination of the certificate has taken place, the remaining information contained in the major and minor fields may be displayed to the user. These may include the display of the state logo at step 1202, display of the driver's name at step 1204, the photo of the driver at step 1206, the birth date at step 1208, and any restrictions of the driver at step 1210. This can allow verification of the identity of the holder of the certificate. The validity of the license may also be checked at step 1212, for example, by querying a remote system. If the license is not valid, the user is alerted at step 1216. If it is valid, unless other actions are required to be performed (in which case process 1200 will have additional steps), process 1200 is complete. Process 1300 shows an example of a credit card transaction application. Step 1302 displays the logo from the certificate. This ensures brand identity, for example, for on-line and point-of-sale transactions wherein no physical "card" or medium is handled by a user. Subsequent thereto, the customer signature can be displayed at step 1304, for verification purposes, and the customer photo, if any, can be displayed at step 1306. Credit of the account is then verified at step 1308, using any known technique, and if sufficient credit does not exist as detected at step 1310, the user is alerted at step 1312. The process is then complete. In the event of the requirement of verification of the holder of the credit card certificate, a password may be queried for at step 1314, and if the password is not valid, as detected at step 1316, the user can be alerted at step 1312. If the password is valid, a user abort test is performed at step 1318 and if no abort is detected, the transaction is allowed to proceed, step 1320. In any event, the process is complete. Other steps may be performed within the credit card transaction application process 1300, and steps illustrated may be omitted, according to the specific application, the specific minor type of the credit card, etc. . . . Thus, in conclusion, a method and apparatus for formatting and using digital certificates containing extensions with multimedia data has been described. The use of certificates, as described above, as containers for data of various multimedia types is especially useful. This is particularly so for verification methods for commercial transactions, such as visual, password, and biometric verification of holders of such certificates. Although the present invention has been described with reference to certain specific embodiments thereof, the present invention should be construed as limited by the appended claims which follow.
|
Same subclass Same class Consider this |
||||||||||