Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Central trusted authority provides computer authentication
Reexamination Certificate
1999-11-16
2002-11-19
Darrow, Justin T. (Department: 2132)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Central trusted authority provides computer authentication
C713S156000, C713S157000, C705S065000, C705S066000, C380S030000
Reexamination Certificate
active
06484259
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to cryptography and, more particularly, to methods and arrangements that allow widely disparate portable tokens to be employed within a static machine concentric cryptographic environment.
BACKGROUND
Cryptography is commonly employed to authenticate data, encode data, or encrypt/decrypt data in a manner that allows the data to be stored and/or transmitted securely. Cryptography is becoming more and more popular as computers and networks increase in number, size and complexity.
By way of example, public/private key pairs are commonly used in personal computers (PCs) to provide asymmetric encryption of data that is exchanged between communicating parties. Asymmetric encryption uses public-key encryption algorithms. Public-key algorithms use two different keys (known as a key pair), namely, a public key and a private key. These two keys are typically derived from extremely large prime numbers making them mathematically related. However, it is practically impossible to derive one key from the other. As suggested by their names, the public key is made public, while the private key is kept private. In a typical static machine concentric PC environment, the private key may never leave the PC on which it was generated.
Information (i.e., data) that is encrypted with either one of the keys can only be decrypted with the other one of the keys. Thus, for example, data encrypted with the private key can only be decrypted with the public key, and vice versa.
Since, public-key algorithms can be somewhat slow, particularly when encrypting large amounts of data, a digital signature can be used instead to sign the data. A digital signature can be produced by passing the data through a specific one-way hashing algorithm. The hashing algorithm produces a much smaller message digest. As a result of the hashing algorithm, the message digest is a unique value that can essentially act as a “fingerprint” for the larger data file. Once a message digest is created, it can be encrypted, for example, using the private key and attached to the larger data file when it is sent or otherwise provided.
As an additional safety measure, a session key may also be used during a communication session. A session key is essentially a temporary private key or secret that is shared between the communicating parties. Upon decrypting the session key the receiving party can further decrypt the encrypted data by running the hash to produce the message digest, and process it as described above.
One problem associated with such cryptography techniques is that a third party might attempt to masquerade as one of the communicating parties, for example, by fraudulently holding out a public key that is represented to be one of the communicating parties public keys. Any messages or hashes that are intended for the communicating party and encrypted with the fraudulent public key could conceivably be decrypted with the accompanying private key by the third party.
To address this problem and others, a digital certificate can be employed by the communicating parties. A digital certificate is a credential issued by a trusted organization or entity called a certification authority (CA), such as, for example, VeriSign, Inc. This credential typically contains a public key and data that identifies the certificate's subject (i.e., the applicable communicating party). A certificate is usually issued by a CA only after the CA has verified the certificate's subject's identity and has confirmed that the public key included with the certificate belongs to that subject. The certificate may also include a digest of the certificate's contents that is signed with the private key of the CA to ensure that the certificate has not been altered or forged.
A CA may also provide self-signed certificates, or root certificates, that are to be inherently trusted. A CA may itself be certified by a hierarchy of other CAs; such information is usually included within the certificate. When a digital certificate is used to sign documents and software, this information is stored with the signed item in a secure and verifiable form that can be displayed to a user to establish a trust relationship.
Over a period of time, digital certificates will tend to accumulate on a PC. These digital certificates are usually collected in a certificate store. Tools are provided, typically as application programming interface (API) functions, that allow the user to store, retrieve, delete, enumerate, verify, or otherwise maintain the digital certificates within the certificate store.
With this in mind, Microsoft Corp. of Redmond, Wash., develops software, operating systems and other applications for use with a variety of “machines”, including general and special purpose computers, PCs, portable devices, and the like. Microsoft Corp. has developed a Cryptographic API (hereinafter, generically referred to as “CryptoAPI”) that provides a controlled/expandable interface between applications seeking cryptographic services and programs/devices that can provide such cryptographic services. Within CryptoAPI tools (e.g., functions) are provided that can be used to manage the digital certificates in the digital store and attach the digital certificates to data files. For example, CryptoAPI maintains a certificate revocation list (CRL) that is typically issued by the CA and lists digital certificates that are no longer valid. CryptoAPI also supports a certificate trust list (CTL) that identifies items that have been signed by a trusted entity. The various digital certificates, CRLs and CTLs within the certificate store are normally kept in non-volatile memory within the machine, such as, for example, a disk file or the system registry.
The cryptographic programs/devices that can provide the requested cryptographic services may include general purpose and/or special purpose hardware/software that is added to the machine and provides the necessary unique cryptographic token. Thus, for example, CryptoAPI allows new/additional cryptography devices/tokens to be added to the machine and acts as an interface between the requesting application(s) and the added cryptographic device/tokens. This type of API functionality/interface is well known and described in greater detail in U.S. Pat. No. 5,689,565, issued Nov. 18, 1997 to Spies et al.
The above-described API functionality/interface tends to work well with static machine concentric tokens, since it basically assumes that the cryptographic device(s) is fixed in place, always available, and used only by the local machine. However, if some of the tokens are portable, then the API functionality/interface will not always be able to locate the needed token(s).
Consequently, with the recent introduction of smart cards (SCs) and other similar portable token carrying devices, there is a need for improved methods and arrangements that allow widely disparate portable tokens to be used within static machine concentric cryptographic environments. Preferably, these methods and arrangements will provide a generic interface between existing static cryptographic functions and portable cryptographic functions that reduces development efforts/expenditures and increases processing efficiency.
SUMMARY
The present invention provides improved methods and arrangements that can be incorporated into existing static machine concentric machines and/or newly developed appliances to allow a plurality of different portable tokens to be used in support of, or as otherwise necessary for completion of cryptographic functions.
In accordance with certain aspects of the present invention, the methods and arrangements essentially provide a clean and powerful generic interface between the computing machine and the portable token device. Thus, for example, a variety of different portable token vendors may invoke or otherwise access features associated with the present invention in a manner that reduces their development efforts/expenditures while potentially increasing the processing efficiency/capability of their respe
Darrow Justin T.
Lee & Hayes PLLC
Microsoft Corporation
LandOfFree
Methods and arrangements for mapping widely disparate... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and arrangements for mapping widely disparate..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and arrangements for mapping widely disparate... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2991482