CA2278670C - Encryption and decryption method and apparatus - Google Patents
Encryption and decryption method and apparatus Download PDFInfo
- Publication number
- CA2278670C CA2278670C CA002278670A CA2278670A CA2278670C CA 2278670 C CA2278670 C CA 2278670C CA 002278670 A CA002278670 A CA 002278670A CA 2278670 A CA2278670 A CA 2278670A CA 2278670 C CA2278670 C CA 2278670C
- Authority
- CA
- Canada
- Prior art keywords
- server
- certificate
- encrypted
- message
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/80—Wireless
Abstract
A method for efficient encryption and decryption (100) comprises the steps o f encrypting a message (104) at a sending unit which is to be sent to a receiving unit using a mesage key (106) and appending to the message at the sending unit the message key encrypted (108 and 109) using a receiver's publ ic key (110). Subsequently, a sender's certificate (116) is appended at a first server (302) and extracted at a second server (310). The message key is then decrypted at the receiving unit using a receiver's private key (140) to provide a decrypted message key. Subsequently the message is decrypted using the decrypted message key (142 and 143) and authenticated by comparing a pai r of digest (152 and 156).
Description
ENCRYPTION AND DECRYPTION METHOD AND -APPARATUS
Field of the Invention - s This invention relates in general to encryption and decryption and more specifically to efficient attachment of certificates in an encryption/decryption scheme.
Background of the Invention io In a broad sense, efficient paging and security for wireless applications such as paging have opposing constraints. On the one hand, paging uses its non-real time capabilities to pack information efficiently to reduce the inefficient use of the wireless bandwidth.
Security measures such as encryption on the other hand typically add to 15 the information being transmitted over the air. The increased number of users and the increase in the average size of messages (including text, facsimile, audio and eventually video information) will only put further constraints on the use of the limited bandwidth provided.
In the normal process for passing a secured message with 2o signature from a sender to a receiver, the steps in method 10 are typically followed as described with reference to FIG. 1. First the user creates a text message at step 12. Then, the user generates a digest of the text message using a one-way function (e.g. a secure hash function) at step 14. The user then attaches his ~ signature at step 18 by first 2s encrypting the digest using his signature or private key at step 20 and running it through an asymmetric engine 16, typically the private key corresponds to a public key found in a traceable certificate 26. The - message and digital signature are then appended at step 22. The message with signature 24 is then catenated at step 27 to the traceable 3o certificate 26 to create an authenticatable message 28. The authenticatable message 28 is then encrypted by using a symmetric engine 30 and a session key 32 to provide an encrypted message 40. The session key 32 (normally a random symmetric key) is itself encrypted ' using a recipient's asymmetric public key 34 and an asymmetric engine 36 to create a digital envelope 38. The encrypted message 40 is then appended at step 42 to the digital envelope 38 to create an encrypted s message plus signature plus certificate with envelope 44.
With reference to FIG. 2, the typical decryption process begins by separating (46) the components of the encrypted message plus signature plus certificate with envelope 44 into the encrypted message 56 and a digital envelope 48. Preferably, digital envelope 48 is the same as digital io envelope 38 from FIG. 1. The session key 54 (preferably session key 54 is the same as session key 32 of FIG. 1) is recovered (decrypted) by the recipient using their private key 52 (corresponding to the recipient's private key 34) and running the digital envelope 48 through an asymmetric engine 49 using the private key 52. The encrypted message 1s 56 with signature is decrypted using the session key 54. In other words, by using the session key 54 the encrypted message 56 is run through a symmetric engine 58 to obtain an authenticatable message 60 (which should be the same as the authenticatable message 28 of FIG. 1). Thus, the recipient can confirm (to a reasonable degree) the identity of the 2o sender of the message as will be seen in the next few steps. Next, the authenticatable message is separated (62) into a certificate 64 and a separate signed message 68 corresponding respectivley to the certificate 26 and signed message 24 of FIG. 1. The signed message 68 itself will also be separated (70) into a readable text message 80 and a digital signature 72 corresponding respectively to the message 12 and digital signature 18 of FIG. 1. A sender's public key 66 is extracted from the certificate 64 and then used to decrypt the signature into a digest 77. In other words, the digital signature 72 is passed through an asymmetric engine 74 using the sender's public key 66 to provide a digest 77 which so should be a copy of the actual digest. The text message 80 is run through the same (hash) function (as in step 14 of FIG. 1) to retrieve the actual digest 79. The actual digest 79 and the digest 77 are compared at WO 98!34374 PCT/US98/00291 step 76 to verify proper signature. Note that in the example above, the ' certificate is embedded in the encrypted message and significantly increases the size of the encrypted message.
s Brief Description of the Drawings FIG. 1 is a flow chart of an known encryption method for sending information.
FIG. 2 is a flow chart of an known decryption method for to receiving information.
FIG. 3 is a flow chart of an encryption method in accordance with an embodiment of the present invention.
FIG. 4 is another flow chart of an encryption method i n accordance with an alternative embodiment of the present invention.
15 FIG. 5 is a block diagram of a certificate server in accordance with the present invention.
Detailed Description zo Referring to FIG. 3, a method for efficient encryption and decryption is shown comprising the steps of encrypting a message 102 at a sending unit which is to be sent to a receiving unit using a message key 112. Then, the message key is appended to the message at the sending unit using a receiver's public ~ key 110. Preferably, this step 2s comprises the steps of adding a signature by generating a digest of the message using a one-way function 104 and encrypting the digest using the sender's private key 106 to create a signed message, the private key corresponding to the public key embedded in a sender's certificate (116).
Subsequently a sender's certificate is appended at a first server. Next, ' so the sender's certificate is extracted (134) at a second server and then the message key is decrypted at the receiving unit using a receiver's private key 140 to provide a decrypted message key. Subsequently, the message is decrypted using the decrypted message key. Additionally the method -can further comprise the steps of encrypting the signed message using a sender-receiver session key 108 providing an encrypted signed message, and decrypting the encrypted signed message at the receiver using s another sender-receiver session key 142. Preferably, the sender-receiver session key is encrypted using a receiver's public key retrieved from the first server and catenated to the signed message as an envelope.
In another embodiment of the present invention, a method of efficiently transporting an encrypted signed message with envelope ~o from a sender to a receiver using a sending server and a receiving server, comprises the steps of encrypting a certificate using a server-to-server session key 118 to create an encrypted certificate and catenating the encrypted certificate with an envelope containing the server-to-server session key encrypted with a receiving server's asymmetric 15 public key 120 to create an encrypted certificate with envelope and then catenating the encrypted signed message with envelope to the encrypted certificate with envelope. The method can further comprise the steps of decrypting the server-to-server session key using the receiving server's private key 130 as well as the step of separating the 2o certificate from the encrypted signed message with envelope and further decrypting the certificate using the server to server session key 132. Additionally, the method could include the step of extracting the sender's public key from a certificate at the receiving server. At the receiving unit, the envelope can be separated from the encrypted signed a~ message, wherein the envelope is decrypted to provide a sender-receiver session key. Also the encrypted signed message and signature can be decrypted using the sender-receiver session key. As will be explained in further detail, the signature at the receiver can be decrypted into a digest using the sender's public key for use in eo authentication of the signature associated with the message. Thus, authentication is done by separating the message by passing the message through a one way function and obtaining an actual digest which is compared with the digest found by decrypting the signature -using the sender's public key.
_ Again, referring to FIG. 3, the method 100 illustrates how an encrypted message is sent from a sending unit to a receiving unit s without having to transmit the certificate to the receiving unit which is particularly useful when the path between the sending unit and receiving unit is wireless. As before, the user creates a text message at step 102 and subsequently generates a digest of the text message using a one-way function (e.g. secure hash) at step 104. The user makes his ~o signature by encrypting the digest using his signature key through an asymmetric engine 106 and appending the result to the message at step 105, wherein the signature key is typically a private key corresponding to the public key found in a certificate, preferably a traceable certificate.
The signed message is then encrypted using a sender-receiver session is key at step 108 (normally a random symmetric key). The sender-receiver session key itself is encrypted using the receiver's public key at step 110 and catenated at step 109 to the signed message as an envelope.
Preferably, a random source 114 is used to generate the keys at steps 108 and 110. The receiver's public key can be resident in a key file 112 or 2o preferably extracted from a sender's certificate database 116 as needed.
The traceable certificate or sender's certificate (116) is encrypted using a server-server session key at step 118 (normally a random symmetric key) and then catenated at step 119 to the encrypted signed message with envelope. Optionally, this is the same session key as sender-2s receiver key, but this requires the server be trusted. The server-server session key (normally a random symmetric key also) is itself encrypted using the receiving server's asymmetric public key at step 120 and catenated at step 121 to the encrypted signed message with envelope plus encrypted certificate. Preferably, a random source 122 is used to ' 3o generate the keys at steps 118 and 120.
At the receiving end (from the server-to-server perspective), the encrypted server-server session key is recovered by the receiving server using its asymmetric private key at step 130. The encrypted certificate (126) is separated at steps 123 and 127 from the encrypted signed message with envelope (124 or 125), and decrypted using the session key at step 132. The sender's public key is preferably extracted from the s certificate in the certificate database 134 and authentication is done if necessary by sending the needed information to a key file 136 for later comparison. Authentication preferably involves a traceable certificate that allows for the tracing of origin of the authority signing as to the authenticity of the certificate holder. The information embedded in a yo certificate could include a signature of a higher authority linking the hierarchy of traceable authorities. Thus, authentication is performed by checking the signature of the authority attesting to the certificate's authenticity and the public key is then filed in the key file, along with some identifying information and validity, having been authenticated.
15 If the receiver has the public key already, no action is taken by the server, except to identify proper public key (the sender's) to the receiver.
If the receiver does not have the key, the server may send the whole certificate or only part of the certificate, (e.g. the public key), as mutually agreed between the sending and receiving parties. Next, the envelope 20 (138) is separated at step 137 from the encrypted signed message (139) and decrypted by the receiver using the sender-receiver session key at step 142. The session key (142) is used to decrypt the message plus signature. The signature (146) is decrypted with sender's public key (which can be obtained from the key file ~ 136 if not already available) at 2s step 148 to provide the digest (152) after the message is separated from the signature at step 143. The message is separated (144 and 145) and passed through the one-way function 154 to get the actual digest 156 of the message. The digest 152 is compared with the actual digest 156 to verify proper signature. Note that authentication of signature is ao optional, but desirable especially for financial applications.
As shown above, the over-the-air traffic is reduced by not sending the certificate embedded in the inbound message but instead having the certificate or directory server append it from a file. -Typically, these certificates are thousands of bits in length, compared to only a few hundred for the whole message and signature. Certificates are normally covered by encryption to provide some degree of privacy s to the transactors.
The server, in effect, provides the sender or receiver or both with a public-key (asymmetric-key) certificate directory service, which is the new arrangement compared to prior schemes. Symmetric encryption is shown between the sending unit (messaging device) and the receiving io unit and is labeled "end-end session". This is optional but likely and would be used if privacy of the transaction, not just authentication and signature, were required. This encryption most likely would be symmetric because of its simplicity and efficiency, but asymmetric could also be used.
is Addressing, control and authentication information are not shown passing between sender and server or carrier, but these are necessary for messaging purposes. The authentication is used between the server and the device, to assure the server that the device is the true source so that the proper certificate can be appended. Control would 2o entail such features as priority of processing and delivery, level of security, and other ancillary functions. Addressing may be done in the clear or through the server-device encryption, if present. Since privacy is becoming more of an issue every day, even addressing may need to be protected from prying eyes when using a broadcast medium.
a~ Referring to FIG. 5, a remote certificate server 300 for use in wireless communication comprises a sender server portion 302 for receiving an encrypted wireless message with envelope as well as a memory 304 for storing the encrypted wireless message. The sender server portion also comprises a processor 306 for encrypting a certificate so with a server to server session key to provide an encrypted certificate.
The processor 306 also appends the encrypted certificate with the encrypted wireless message with envelope to provide an encrypted WO 98/343?4 PCT/US98/00291 certificate and wireless message with envelope. The processor 306 -further encrypts the server to server session key by using a receiver server portion's asymmetric public key to provide an encrypted server to server session key, wherein the encrypted server to server session s key is appended to the encrypted certificate and wireless message with envelope. The remote certificate server 300 further comprises a receiver server portion 310 for receiving the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope. The receiver server portion 310 preferably comprises a 1o memory 308 for storing the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope and a processor 309 for recovering the server to server session key using an asymmetric private key corresponding to the receiver server portion's asymmetric public key and for separating the encrypted is certificate from the encrypted wireless message with envelope and for decrypting the encrypted certificate. It should be noted that the sender server portion 302 and the receiver server portion 310 of the remote certificate server 300 can either be hardwired together or coupled together via a wireline network or wireless network as desired.
2o The receiver's public key or the receiving unit's certificate must be transferred from the server to the sender. The server can send the whole certificate and allow the sender to authenticate the embedded information, or the sender and server could have a trusted relationship allowing the sender to get just the key portion of the certificate for 2s placement in a key file as shown with step 212 in FIG. 3. For minimizing problems later the server should also advise the expiration or validity of the key, and for minimizing traffic later sender and server should agree on a token to represent certificate holder, such as a tag or name.
so Referring again to FIG. 3, the end-end session key may be symmetric as noted previously. Typically, symmetric keys require additional synchronization (e.g. start vector) information to work _g_ properly. This is not shown explicitly in the diagram. This also applies to the server-server session key. The certificate (plus any additional routing and relaying information) is covered by this session key.
Synchronization information for this key may be derived from the end-s end session key's synchronization or other information already on the . channel to lower overhead. The key itself may be the same key used for the end-end session, but this would create a potential security problem.
The problem is that the servers would be fully capable of decrypting the message. If both servers are trusted by both sender and receiver, this to poses no problem. Avoiding this problem and a general solution would require the server-server session key to be unique from the end-end session key.
The receiver and the receiving server can be one and the same entity, making life simple. The sender's certificate can be separated ~s from the incoming message and authenticated (not shown) and filed away. When a messaging device is the receiver of such a message reducing over-the-air traffic can be similarly reduced, but it is somewhat more difficult. The sender's certificate in its entirety is held by the receiver or just the key of the sender. The sending server does 2o not suthomatically send the certificate unless needed, which reduces traffic to only a single transmission of the certificate in many cases.
Further, the receiver and receiving server may be connected to a wired network where traffic considerations are less constraining. The message may be decrypted when the messaging device has just the key, 2s but traceability is lost unless the whole certificate is held by the messaging device until verified. The sender and sending server, likewise, can be one and the same entity, especially if there is no wireless path from the sender.
The receiving server may be trusted or untrusted. If trusted, ' so then the messaging device holds just the key. If untrusted, then the messaging device holds the whole certificate. The implication o n memory and processing in the device for untrusted is to require much larger capacity, at least temporarily while the certificate is being ' authenticated. Once authenticated, only the key and its expiration need be kept. Over-the-air traffic also increases to allow transmission of certificates to recipients and their authentication from the root s authority. The server could strip off the certificates that are not needed and simply send the ones that have never been sent before. This is like the sending server's treatment or receiver certificate with tags or names. Even if the certificate has already been sent once if the receiver does not recognize the tag or name the server uses, it can refresh the io certificate or key. An example of several of these embodiments can be seen with respect to FIG. 4.
FIG. 4 illustrates an alternative embodiment of a method for sending a message from a sending unit to a receiving unit. In particular, the method 200 illustrates how an encrypted message is sent 15 from a sending unit to a receiving unit without necessarily having to transmit a certificate to the receiving unit every time a message is sent.
As before, the user creates a text message at step 202 and subsequently generates a digest of the text message using a one-way function (e.g.
secure hash) at step 204. The user makes his signature by encrypting the 2o digest using his signature key through an asymmetric engine 206 and appending the result to the message at step 205, wherein the signature key is typically a private key corresponding to the public key found in a traceable certificate. The signed message is then encrypted using a sender-receiver session key (or end-to-end session key) at step 208 2s (normally a random symmetric key). The sender-receiver session key itself is encrypted using the receiver's public key at step 210 and catenated at step 209 to the signed message as an envelope. Preferably, a random source 214 is used to generate the keys at steps 208 and 210. The receiver's public key can be resident in a key file 212 or preferably 3o extracted from a sender's certificate database 216 as needed.
The sending unit can send the signed message with envelope directly to the receiving unit without requiring anything further from -zo-the servers at step 211. For instance, if messages were previously sent -between the sending unit and the receiving unit, the receiving unit may already have a certificate available (at the receiving unit} to authenticate the message. Alternatively, the receiving unit may only - s require a key from a key file (231) to authenticate the message. In other words, the receiving unit may only require portions of information from the certificate (rather than the entire certificate) that would aide i n reducing the over-the-air traffic seen between two frequent communicators such as a merchant and frequent purchaser.
to Thus, in one embodiment of the present invention, the sending of a message (211) from a sending unit to receiving unit could entail an alternative path 213 where the messages are catenated at step 223 with an encrypted traceable certificate or sender's certificate (216} with envelope. The certificate 216 is preferably encrypted using a server-ys server session key at step 218 (normally a random symmetric key) and then catenated at step 221 with the receiving server's public key 220 to provide an encrypted certificate with envelope. Preferably, a random source 222 is used to generate the keys at steps 218 and 220. The encrypted message with envelope and the encrypted certificate with 2o envelope can either run through a similar decryption algorithm as previously described with respect to FIG. 3, or the encrypted message can take the alternate route 227 through step 225 to the receiving unit where no information or minimal information is required from the receiving server to decrypt and/or authenticate the encrypted message.
is In the event the entire certificate or a portion of the certificate is required, the envelope and encrypted certificate are separated at step 229. The receiving server's private key 224 is used to authenticate the server sending the information and the server-server session key 226 is used to decrypt the certificate which is stored in the certificate database 30 228. The certificate or appropriate portion of the certificate (such as the key) can be forwarded to the key file 231 for subsequent authentication by the receiving unit. Whether the signed encrypted message with envelope is sent by path 211 or 227, the envelope is separated from the -signed encrypted message at step 233. The receiver's public key at step 232 is used to strip away the envelope and an end-end session key at step 234 decrypts the signed encrypted message. Once again, the signed s encrypted message itself is separated at step 235 into a message and signature. The message is passed through a hash function 240 to get the actual digest 242 of the message. The signature is decrypted using the sender's public key at step 236 to obtain the digest 244. Then the digest 244 is compared with the actual digest 242 to verify proper signature.
io Note again that authentication of signature is optional, but desirable especially for financial applications.
FIG. 4 illustrates the two alternatives in accordance with the present invention. In a first case, the message is encrypted and delivered without a certificate to the receiving unit (211) while is separately (triggered by the sending unit) the servers communicate and decide if a copy of the certificate needs to be delivered to the receiving unit (preferably in an encrypted form as shown}. The receiving server then decrypts, stores, and delivers the certificate or the key of the certificate as needed by the receiving unit. In a second case, the message 2o is encrypted and then appended to the certificate. The certificate itself is preferably encrypted by the server. The encrypted message as well as the encrypted certificate are then delivered to the receiving server, wherein the receiving server detaches the certificate, decrypts it, stores it and delivers either the certificate or the key to the receiving unit.
a~ In a broad aspect of the invention, a method of efficiently transporting a signed message from a sender to a receiver using a sending server and a receiving server comprises the steps of sending a signed message from a sending unit for receipt at a receiving unit and then subsequently appending a sender's certificate at a first server to the so signed message. The sender's certificate and even the signed message may optionally be encrypted. At a second server, the sender's certificate is extracted and thus the signed message is received and read at the receiving unit using a set of information extracted from the sender's ' certificate. The set of information is preferably selected from the group of name, a public key, signature authority, expiration date, validity period, date of issue, control numbers, or other information as s appropriate.
A personal messaging unit (PMU) or subscriber unit capable of receiving or coupling to a smartcard is within contemplation of the claims of the present invention. Actual implementation could include a PMU with contacts for inserting a smartcard, or a PMU with a separate io interface unit for smartcards connected by cable to the PMU, or a PMU
with an embedded smartcard that is either fixed or removable. The certificate server may be implemented as a self-contained unit (even internal to the PMU) or as a software program running within a messaging switch (paging or messaging terminal) or as an external is switch outside the paging system domain altogether. It would be assumed that the certificate server would provide for fully compatible protocol support with the correspondent entity, including use of appropriate encryption schemes and access to root authorities for authentications.
2o It should be understood that the disclosed embodiments are merely examples and the invention is not restricted thereto. It will be understood by those skilled in the art that variations and modifications can be made within the scope and spirit of the present invention as defined by the appended claims.
Field of the Invention - s This invention relates in general to encryption and decryption and more specifically to efficient attachment of certificates in an encryption/decryption scheme.
Background of the Invention io In a broad sense, efficient paging and security for wireless applications such as paging have opposing constraints. On the one hand, paging uses its non-real time capabilities to pack information efficiently to reduce the inefficient use of the wireless bandwidth.
Security measures such as encryption on the other hand typically add to 15 the information being transmitted over the air. The increased number of users and the increase in the average size of messages (including text, facsimile, audio and eventually video information) will only put further constraints on the use of the limited bandwidth provided.
In the normal process for passing a secured message with 2o signature from a sender to a receiver, the steps in method 10 are typically followed as described with reference to FIG. 1. First the user creates a text message at step 12. Then, the user generates a digest of the text message using a one-way function (e.g. a secure hash function) at step 14. The user then attaches his ~ signature at step 18 by first 2s encrypting the digest using his signature or private key at step 20 and running it through an asymmetric engine 16, typically the private key corresponds to a public key found in a traceable certificate 26. The - message and digital signature are then appended at step 22. The message with signature 24 is then catenated at step 27 to the traceable 3o certificate 26 to create an authenticatable message 28. The authenticatable message 28 is then encrypted by using a symmetric engine 30 and a session key 32 to provide an encrypted message 40. The session key 32 (normally a random symmetric key) is itself encrypted ' using a recipient's asymmetric public key 34 and an asymmetric engine 36 to create a digital envelope 38. The encrypted message 40 is then appended at step 42 to the digital envelope 38 to create an encrypted s message plus signature plus certificate with envelope 44.
With reference to FIG. 2, the typical decryption process begins by separating (46) the components of the encrypted message plus signature plus certificate with envelope 44 into the encrypted message 56 and a digital envelope 48. Preferably, digital envelope 48 is the same as digital io envelope 38 from FIG. 1. The session key 54 (preferably session key 54 is the same as session key 32 of FIG. 1) is recovered (decrypted) by the recipient using their private key 52 (corresponding to the recipient's private key 34) and running the digital envelope 48 through an asymmetric engine 49 using the private key 52. The encrypted message 1s 56 with signature is decrypted using the session key 54. In other words, by using the session key 54 the encrypted message 56 is run through a symmetric engine 58 to obtain an authenticatable message 60 (which should be the same as the authenticatable message 28 of FIG. 1). Thus, the recipient can confirm (to a reasonable degree) the identity of the 2o sender of the message as will be seen in the next few steps. Next, the authenticatable message is separated (62) into a certificate 64 and a separate signed message 68 corresponding respectivley to the certificate 26 and signed message 24 of FIG. 1. The signed message 68 itself will also be separated (70) into a readable text message 80 and a digital signature 72 corresponding respectively to the message 12 and digital signature 18 of FIG. 1. A sender's public key 66 is extracted from the certificate 64 and then used to decrypt the signature into a digest 77. In other words, the digital signature 72 is passed through an asymmetric engine 74 using the sender's public key 66 to provide a digest 77 which so should be a copy of the actual digest. The text message 80 is run through the same (hash) function (as in step 14 of FIG. 1) to retrieve the actual digest 79. The actual digest 79 and the digest 77 are compared at WO 98!34374 PCT/US98/00291 step 76 to verify proper signature. Note that in the example above, the ' certificate is embedded in the encrypted message and significantly increases the size of the encrypted message.
s Brief Description of the Drawings FIG. 1 is a flow chart of an known encryption method for sending information.
FIG. 2 is a flow chart of an known decryption method for to receiving information.
FIG. 3 is a flow chart of an encryption method in accordance with an embodiment of the present invention.
FIG. 4 is another flow chart of an encryption method i n accordance with an alternative embodiment of the present invention.
15 FIG. 5 is a block diagram of a certificate server in accordance with the present invention.
Detailed Description zo Referring to FIG. 3, a method for efficient encryption and decryption is shown comprising the steps of encrypting a message 102 at a sending unit which is to be sent to a receiving unit using a message key 112. Then, the message key is appended to the message at the sending unit using a receiver's public ~ key 110. Preferably, this step 2s comprises the steps of adding a signature by generating a digest of the message using a one-way function 104 and encrypting the digest using the sender's private key 106 to create a signed message, the private key corresponding to the public key embedded in a sender's certificate (116).
Subsequently a sender's certificate is appended at a first server. Next, ' so the sender's certificate is extracted (134) at a second server and then the message key is decrypted at the receiving unit using a receiver's private key 140 to provide a decrypted message key. Subsequently, the message is decrypted using the decrypted message key. Additionally the method -can further comprise the steps of encrypting the signed message using a sender-receiver session key 108 providing an encrypted signed message, and decrypting the encrypted signed message at the receiver using s another sender-receiver session key 142. Preferably, the sender-receiver session key is encrypted using a receiver's public key retrieved from the first server and catenated to the signed message as an envelope.
In another embodiment of the present invention, a method of efficiently transporting an encrypted signed message with envelope ~o from a sender to a receiver using a sending server and a receiving server, comprises the steps of encrypting a certificate using a server-to-server session key 118 to create an encrypted certificate and catenating the encrypted certificate with an envelope containing the server-to-server session key encrypted with a receiving server's asymmetric 15 public key 120 to create an encrypted certificate with envelope and then catenating the encrypted signed message with envelope to the encrypted certificate with envelope. The method can further comprise the steps of decrypting the server-to-server session key using the receiving server's private key 130 as well as the step of separating the 2o certificate from the encrypted signed message with envelope and further decrypting the certificate using the server to server session key 132. Additionally, the method could include the step of extracting the sender's public key from a certificate at the receiving server. At the receiving unit, the envelope can be separated from the encrypted signed a~ message, wherein the envelope is decrypted to provide a sender-receiver session key. Also the encrypted signed message and signature can be decrypted using the sender-receiver session key. As will be explained in further detail, the signature at the receiver can be decrypted into a digest using the sender's public key for use in eo authentication of the signature associated with the message. Thus, authentication is done by separating the message by passing the message through a one way function and obtaining an actual digest which is compared with the digest found by decrypting the signature -using the sender's public key.
_ Again, referring to FIG. 3, the method 100 illustrates how an encrypted message is sent from a sending unit to a receiving unit s without having to transmit the certificate to the receiving unit which is particularly useful when the path between the sending unit and receiving unit is wireless. As before, the user creates a text message at step 102 and subsequently generates a digest of the text message using a one-way function (e.g. secure hash) at step 104. The user makes his ~o signature by encrypting the digest using his signature key through an asymmetric engine 106 and appending the result to the message at step 105, wherein the signature key is typically a private key corresponding to the public key found in a certificate, preferably a traceable certificate.
The signed message is then encrypted using a sender-receiver session is key at step 108 (normally a random symmetric key). The sender-receiver session key itself is encrypted using the receiver's public key at step 110 and catenated at step 109 to the signed message as an envelope.
Preferably, a random source 114 is used to generate the keys at steps 108 and 110. The receiver's public key can be resident in a key file 112 or 2o preferably extracted from a sender's certificate database 116 as needed.
The traceable certificate or sender's certificate (116) is encrypted using a server-server session key at step 118 (normally a random symmetric key) and then catenated at step 119 to the encrypted signed message with envelope. Optionally, this is the same session key as sender-2s receiver key, but this requires the server be trusted. The server-server session key (normally a random symmetric key also) is itself encrypted using the receiving server's asymmetric public key at step 120 and catenated at step 121 to the encrypted signed message with envelope plus encrypted certificate. Preferably, a random source 122 is used to ' 3o generate the keys at steps 118 and 120.
At the receiving end (from the server-to-server perspective), the encrypted server-server session key is recovered by the receiving server using its asymmetric private key at step 130. The encrypted certificate (126) is separated at steps 123 and 127 from the encrypted signed message with envelope (124 or 125), and decrypted using the session key at step 132. The sender's public key is preferably extracted from the s certificate in the certificate database 134 and authentication is done if necessary by sending the needed information to a key file 136 for later comparison. Authentication preferably involves a traceable certificate that allows for the tracing of origin of the authority signing as to the authenticity of the certificate holder. The information embedded in a yo certificate could include a signature of a higher authority linking the hierarchy of traceable authorities. Thus, authentication is performed by checking the signature of the authority attesting to the certificate's authenticity and the public key is then filed in the key file, along with some identifying information and validity, having been authenticated.
15 If the receiver has the public key already, no action is taken by the server, except to identify proper public key (the sender's) to the receiver.
If the receiver does not have the key, the server may send the whole certificate or only part of the certificate, (e.g. the public key), as mutually agreed between the sending and receiving parties. Next, the envelope 20 (138) is separated at step 137 from the encrypted signed message (139) and decrypted by the receiver using the sender-receiver session key at step 142. The session key (142) is used to decrypt the message plus signature. The signature (146) is decrypted with sender's public key (which can be obtained from the key file ~ 136 if not already available) at 2s step 148 to provide the digest (152) after the message is separated from the signature at step 143. The message is separated (144 and 145) and passed through the one-way function 154 to get the actual digest 156 of the message. The digest 152 is compared with the actual digest 156 to verify proper signature. Note that authentication of signature is ao optional, but desirable especially for financial applications.
As shown above, the over-the-air traffic is reduced by not sending the certificate embedded in the inbound message but instead having the certificate or directory server append it from a file. -Typically, these certificates are thousands of bits in length, compared to only a few hundred for the whole message and signature. Certificates are normally covered by encryption to provide some degree of privacy s to the transactors.
The server, in effect, provides the sender or receiver or both with a public-key (asymmetric-key) certificate directory service, which is the new arrangement compared to prior schemes. Symmetric encryption is shown between the sending unit (messaging device) and the receiving io unit and is labeled "end-end session". This is optional but likely and would be used if privacy of the transaction, not just authentication and signature, were required. This encryption most likely would be symmetric because of its simplicity and efficiency, but asymmetric could also be used.
is Addressing, control and authentication information are not shown passing between sender and server or carrier, but these are necessary for messaging purposes. The authentication is used between the server and the device, to assure the server that the device is the true source so that the proper certificate can be appended. Control would 2o entail such features as priority of processing and delivery, level of security, and other ancillary functions. Addressing may be done in the clear or through the server-device encryption, if present. Since privacy is becoming more of an issue every day, even addressing may need to be protected from prying eyes when using a broadcast medium.
a~ Referring to FIG. 5, a remote certificate server 300 for use in wireless communication comprises a sender server portion 302 for receiving an encrypted wireless message with envelope as well as a memory 304 for storing the encrypted wireless message. The sender server portion also comprises a processor 306 for encrypting a certificate so with a server to server session key to provide an encrypted certificate.
The processor 306 also appends the encrypted certificate with the encrypted wireless message with envelope to provide an encrypted WO 98/343?4 PCT/US98/00291 certificate and wireless message with envelope. The processor 306 -further encrypts the server to server session key by using a receiver server portion's asymmetric public key to provide an encrypted server to server session key, wherein the encrypted server to server session s key is appended to the encrypted certificate and wireless message with envelope. The remote certificate server 300 further comprises a receiver server portion 310 for receiving the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope. The receiver server portion 310 preferably comprises a 1o memory 308 for storing the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope and a processor 309 for recovering the server to server session key using an asymmetric private key corresponding to the receiver server portion's asymmetric public key and for separating the encrypted is certificate from the encrypted wireless message with envelope and for decrypting the encrypted certificate. It should be noted that the sender server portion 302 and the receiver server portion 310 of the remote certificate server 300 can either be hardwired together or coupled together via a wireline network or wireless network as desired.
2o The receiver's public key or the receiving unit's certificate must be transferred from the server to the sender. The server can send the whole certificate and allow the sender to authenticate the embedded information, or the sender and server could have a trusted relationship allowing the sender to get just the key portion of the certificate for 2s placement in a key file as shown with step 212 in FIG. 3. For minimizing problems later the server should also advise the expiration or validity of the key, and for minimizing traffic later sender and server should agree on a token to represent certificate holder, such as a tag or name.
so Referring again to FIG. 3, the end-end session key may be symmetric as noted previously. Typically, symmetric keys require additional synchronization (e.g. start vector) information to work _g_ properly. This is not shown explicitly in the diagram. This also applies to the server-server session key. The certificate (plus any additional routing and relaying information) is covered by this session key.
Synchronization information for this key may be derived from the end-s end session key's synchronization or other information already on the . channel to lower overhead. The key itself may be the same key used for the end-end session, but this would create a potential security problem.
The problem is that the servers would be fully capable of decrypting the message. If both servers are trusted by both sender and receiver, this to poses no problem. Avoiding this problem and a general solution would require the server-server session key to be unique from the end-end session key.
The receiver and the receiving server can be one and the same entity, making life simple. The sender's certificate can be separated ~s from the incoming message and authenticated (not shown) and filed away. When a messaging device is the receiver of such a message reducing over-the-air traffic can be similarly reduced, but it is somewhat more difficult. The sender's certificate in its entirety is held by the receiver or just the key of the sender. The sending server does 2o not suthomatically send the certificate unless needed, which reduces traffic to only a single transmission of the certificate in many cases.
Further, the receiver and receiving server may be connected to a wired network where traffic considerations are less constraining. The message may be decrypted when the messaging device has just the key, 2s but traceability is lost unless the whole certificate is held by the messaging device until verified. The sender and sending server, likewise, can be one and the same entity, especially if there is no wireless path from the sender.
The receiving server may be trusted or untrusted. If trusted, ' so then the messaging device holds just the key. If untrusted, then the messaging device holds the whole certificate. The implication o n memory and processing in the device for untrusted is to require much larger capacity, at least temporarily while the certificate is being ' authenticated. Once authenticated, only the key and its expiration need be kept. Over-the-air traffic also increases to allow transmission of certificates to recipients and their authentication from the root s authority. The server could strip off the certificates that are not needed and simply send the ones that have never been sent before. This is like the sending server's treatment or receiver certificate with tags or names. Even if the certificate has already been sent once if the receiver does not recognize the tag or name the server uses, it can refresh the io certificate or key. An example of several of these embodiments can be seen with respect to FIG. 4.
FIG. 4 illustrates an alternative embodiment of a method for sending a message from a sending unit to a receiving unit. In particular, the method 200 illustrates how an encrypted message is sent 15 from a sending unit to a receiving unit without necessarily having to transmit a certificate to the receiving unit every time a message is sent.
As before, the user creates a text message at step 202 and subsequently generates a digest of the text message using a one-way function (e.g.
secure hash) at step 204. The user makes his signature by encrypting the 2o digest using his signature key through an asymmetric engine 206 and appending the result to the message at step 205, wherein the signature key is typically a private key corresponding to the public key found in a traceable certificate. The signed message is then encrypted using a sender-receiver session key (or end-to-end session key) at step 208 2s (normally a random symmetric key). The sender-receiver session key itself is encrypted using the receiver's public key at step 210 and catenated at step 209 to the signed message as an envelope. Preferably, a random source 214 is used to generate the keys at steps 208 and 210. The receiver's public key can be resident in a key file 212 or preferably 3o extracted from a sender's certificate database 216 as needed.
The sending unit can send the signed message with envelope directly to the receiving unit without requiring anything further from -zo-the servers at step 211. For instance, if messages were previously sent -between the sending unit and the receiving unit, the receiving unit may already have a certificate available (at the receiving unit} to authenticate the message. Alternatively, the receiving unit may only - s require a key from a key file (231) to authenticate the message. In other words, the receiving unit may only require portions of information from the certificate (rather than the entire certificate) that would aide i n reducing the over-the-air traffic seen between two frequent communicators such as a merchant and frequent purchaser.
to Thus, in one embodiment of the present invention, the sending of a message (211) from a sending unit to receiving unit could entail an alternative path 213 where the messages are catenated at step 223 with an encrypted traceable certificate or sender's certificate (216} with envelope. The certificate 216 is preferably encrypted using a server-ys server session key at step 218 (normally a random symmetric key) and then catenated at step 221 with the receiving server's public key 220 to provide an encrypted certificate with envelope. Preferably, a random source 222 is used to generate the keys at steps 218 and 220. The encrypted message with envelope and the encrypted certificate with 2o envelope can either run through a similar decryption algorithm as previously described with respect to FIG. 3, or the encrypted message can take the alternate route 227 through step 225 to the receiving unit where no information or minimal information is required from the receiving server to decrypt and/or authenticate the encrypted message.
is In the event the entire certificate or a portion of the certificate is required, the envelope and encrypted certificate are separated at step 229. The receiving server's private key 224 is used to authenticate the server sending the information and the server-server session key 226 is used to decrypt the certificate which is stored in the certificate database 30 228. The certificate or appropriate portion of the certificate (such as the key) can be forwarded to the key file 231 for subsequent authentication by the receiving unit. Whether the signed encrypted message with envelope is sent by path 211 or 227, the envelope is separated from the -signed encrypted message at step 233. The receiver's public key at step 232 is used to strip away the envelope and an end-end session key at step 234 decrypts the signed encrypted message. Once again, the signed s encrypted message itself is separated at step 235 into a message and signature. The message is passed through a hash function 240 to get the actual digest 242 of the message. The signature is decrypted using the sender's public key at step 236 to obtain the digest 244. Then the digest 244 is compared with the actual digest 242 to verify proper signature.
io Note again that authentication of signature is optional, but desirable especially for financial applications.
FIG. 4 illustrates the two alternatives in accordance with the present invention. In a first case, the message is encrypted and delivered without a certificate to the receiving unit (211) while is separately (triggered by the sending unit) the servers communicate and decide if a copy of the certificate needs to be delivered to the receiving unit (preferably in an encrypted form as shown}. The receiving server then decrypts, stores, and delivers the certificate or the key of the certificate as needed by the receiving unit. In a second case, the message 2o is encrypted and then appended to the certificate. The certificate itself is preferably encrypted by the server. The encrypted message as well as the encrypted certificate are then delivered to the receiving server, wherein the receiving server detaches the certificate, decrypts it, stores it and delivers either the certificate or the key to the receiving unit.
a~ In a broad aspect of the invention, a method of efficiently transporting a signed message from a sender to a receiver using a sending server and a receiving server comprises the steps of sending a signed message from a sending unit for receipt at a receiving unit and then subsequently appending a sender's certificate at a first server to the so signed message. The sender's certificate and even the signed message may optionally be encrypted. At a second server, the sender's certificate is extracted and thus the signed message is received and read at the receiving unit using a set of information extracted from the sender's ' certificate. The set of information is preferably selected from the group of name, a public key, signature authority, expiration date, validity period, date of issue, control numbers, or other information as s appropriate.
A personal messaging unit (PMU) or subscriber unit capable of receiving or coupling to a smartcard is within contemplation of the claims of the present invention. Actual implementation could include a PMU with contacts for inserting a smartcard, or a PMU with a separate io interface unit for smartcards connected by cable to the PMU, or a PMU
with an embedded smartcard that is either fixed or removable. The certificate server may be implemented as a self-contained unit (even internal to the PMU) or as a software program running within a messaging switch (paging or messaging terminal) or as an external is switch outside the paging system domain altogether. It would be assumed that the certificate server would provide for fully compatible protocol support with the correspondent entity, including use of appropriate encryption schemes and access to root authorities for authentications.
2o It should be understood that the disclosed embodiments are merely examples and the invention is not restricted thereto. It will be understood by those skilled in the art that variations and modifications can be made within the scope and spirit of the present invention as defined by the appended claims.
Claims (10)
1. A method for efficient encryption and decryption, comprising the steps of:
encrypting a message at a sending unit which is to be sent to a receiving unit using a message key;
appending to the message at the sending unit the message key encrypted using a receiver's public key;
subsequently appending a sender's certificate at a first server;
extracting the sender's certificate at a second server;
decrypting the message key at the receiving unit using a receiver's private key to provide a decrypted message key;
subsequently decrypting the message using the decrypted message key.
encrypting a message at a sending unit which is to be sent to a receiving unit using a message key;
appending to the message at the sending unit the message key encrypted using a receiver's public key;
subsequently appending a sender's certificate at a first server;
extracting the sender's certificate at a second server;
decrypting the message key at the receiving unit using a receiver's private key to provide a decrypted message key;
subsequently decrypting the message using the decrypted message key.
2. A method for efficient encryption and decryption of claim 1, wherein the step of encrypting a message further comprises the step of adding a signature by generating a digest of the message using a one-way function and encrypting the digest using a private key to create a encrypted signed message, the private key corresponding to the public key embedded in the sender's certificate.
3. A method of efficiently transporting an encrypted signed message with envelope from a sender to a receiver using a sending server and a receiving server, the receiving server using an asymmetric public-private pair of keys, the method comprising the steps of:
encrypting a certificate using a server-to-server session key to create an encrypted certificate and catenating the encrypted certificate with an envelope containing the server-to-server session key encrypted with a receiving server's asymmetric public key to create an encrypted certificate with envelope; and catenating the encrypted signed message with envelope to the encrypted certificate with envelope.
encrypting a certificate using a server-to-server session key to create an encrypted certificate and catenating the encrypted certificate with an envelope containing the server-to-server session key encrypted with a receiving server's asymmetric public key to create an encrypted certificate with envelope; and catenating the encrypted signed message with envelope to the encrypted certificate with envelope.
4. The method of claim 3, wherein the method further comprises the steps of decrypting the server-to-server session key using the receiving server's private key.
5. The method of claim 3, wherein the method further comprises the step of separating the certificate from the encrypted signed message with envelope and further decrypting the certificate using the server to server session key.
6. A remote certificate server for use in wireless communication, comprising:
a sender server portion for receiving an encrypted wireless message with envelope, comprising:
a memory for storing the encrypted wireless message; and a processor for encrypting a certificate with a server to server session key to provided an encrypted certificate and for appending the encrypted certificate with the encrypted wireless message with envelope to provide an encrypted certificate and wireless message with envelope, the processor further encrypting the server to server session key by using a receiver server portion's asymmetric public key to provide an encrypted server to server session key, wherein the encrypted server to server session key is appended to the encrypted certificate and wireless message with envelope.
a sender server portion for receiving an encrypted wireless message with envelope, comprising:
a memory for storing the encrypted wireless message; and a processor for encrypting a certificate with a server to server session key to provided an encrypted certificate and for appending the encrypted certificate with the encrypted wireless message with envelope to provide an encrypted certificate and wireless message with envelope, the processor further encrypting the server to server session key by using a receiver server portion's asymmetric public key to provide an encrypted server to server session key, wherein the encrypted server to server session key is appended to the encrypted certificate and wireless message with envelope.
7. The remote certificate server of claim 6, wherein the remote certificate server further comprises a receiver server portion for receiving the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope, wherein the receiver server portion comprises:
a memory for storing the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope; and a processor for recovering the server to server session key using an asymmetric private key corresponding to the receiver server portion's asymmetric public key and for separating the encrypted certificate from the encrypted wireless message with envelope and for decrypting the encrypted certificate.
a memory for storing the encrypted server to server session key appended to the encrypted certificate and wireless message with envelope; and a processor for recovering the server to server session key using an asymmetric private key corresponding to the receiver server portion's asymmetric public key and for separating the encrypted certificate from the encrypted wireless message with envelope and for decrypting the encrypted certificate.
8. A method of efficiently transporting an encrypted signed message with envelope from a sender to a receiver using a sending server and a receiving server, the receiving server using an asymmetric public-private pair of keys, the method comprising the steps of:
sending the encrypted signed message to the receiver from the sender which triggers an inquiry between the sending server and the receiving server as to whether a certificate needs to be delivered to the receiver;
sending the certificate to the receiver if there is no prior receipt of a certificate or if the certificate is expired or otherwise invalid, otherwise sending portions of the certificate as need as determined by the inquiry between the sending server and the receiving server; and decrypting the certificate or portions of the certificate as need by the receiver.
sending the encrypted signed message to the receiver from the sender which triggers an inquiry between the sending server and the receiving server as to whether a certificate needs to be delivered to the receiver;
sending the certificate to the receiver if there is no prior receipt of a certificate or if the certificate is expired or otherwise invalid, otherwise sending portions of the certificate as need as determined by the inquiry between the sending server and the receiving server; and decrypting the certificate or portions of the certificate as need by the receiver.
9. The method of claim 8, wherein if the inquiry between the sending server and the receiving server determines that a certificate needs to be sent to the receiver, the method then further comprises the steps of:
encrypting the certificate using a server-to-server session key to create an encrypted certificate and catenating the encrypted certificate with an envelope containing the server-to-server session key encrypted with a receiving server's asymmetric public key to create an encrypted certificate with envelope; and catenating the encrypted signed message with envelope to the encrypted certificate with envelope.
encrypting the certificate using a server-to-server session key to create an encrypted certificate and catenating the encrypted certificate with an envelope containing the server-to-server session key encrypted with a receiving server's asymmetric public key to create an encrypted certificate with envelope; and catenating the encrypted signed message with envelope to the encrypted certificate with envelope.
10. A method of efficiently transporting a signed message from a sender to a receiver using a sending server and a receiving server, the method comprising the steps of:
sending a signed message from a sending unit for receipt at a receiving unit;
subsequently appending a sender's certificate at a first server to the signed message;
extracting the sender's certificate at a second server; and receiving the signed message at the receiving unit and reading the message at the receiving unit using a set of information from the sender's certificate.
sending a signed message from a sending unit for receipt at a receiving unit;
subsequently appending a sender's certificate at a first server to the signed message;
extracting the sender's certificate at a second server; and receiving the signed message at the receiving unit and reading the message at the receiving unit using a set of information from the sender's certificate.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/791,968 US6009173A (en) | 1997-01-31 | 1997-01-31 | Encryption and decryption method and apparatus |
| US08/791,968 | 1997-01-31 | ||
| PCT/US1998/000291 WO1998034374A1 (en) | 1997-01-31 | 1998-01-09 | Encryption and decryption method and apparatus |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2278670A1 CA2278670A1 (en) | 1998-08-06 |
| CA2278670C true CA2278670C (en) | 2002-05-28 |
Family
ID=25155395
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002278670A Expired - Fee Related CA2278670C (en) | 1997-01-31 | 1998-01-09 | Encryption and decryption method and apparatus |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6009173A (en) |
| EP (1) | EP0962072A4 (en) |
| KR (1) | KR100380125B1 (en) |
| CN (1) | CN1155198C (en) |
| CA (1) | CA2278670C (en) |
| WO (1) | WO1998034374A1 (en) |
Families Citing this family (144)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6564321B2 (en) | 1995-04-28 | 2003-05-13 | Bobo Ii Charles R | Systems and methods for storing, delivering, and managing messages |
| JP3491665B2 (en) * | 1997-04-16 | 2004-01-26 | ソニー株式会社 | Remote control device and remote control method |
| US6385723B1 (en) * | 1997-05-15 | 2002-05-07 | Mondex International Limited | Key transformation unit for an IC card |
| US6826407B1 (en) | 1999-03-29 | 2004-11-30 | Richard J. Helferich | System and method for integrating audio and visual messaging |
| US6253061B1 (en) | 1997-09-19 | 2001-06-26 | Richard J. Helferich | Systems and methods for delivering information to a transmitting and receiving device |
| US7003304B1 (en) | 1997-09-19 | 2006-02-21 | Thompson Investment Group, Llc | Paging transceivers and methods for selectively retrieving messages |
| US6636733B1 (en) | 1997-09-19 | 2003-10-21 | Thompson Trust | Wireless messaging method |
| US6983138B1 (en) | 1997-12-12 | 2006-01-03 | Richard J. Helferich | User interface for message access |
| FI107984B (en) * | 1998-05-20 | 2001-10-31 | Nokia Networks Oy | Prevention of illegal use of service |
| US6779019B1 (en) | 1998-05-29 | 2004-08-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device |
| US6463463B1 (en) | 1998-05-29 | 2002-10-08 | Research In Motion Limited | System and method for pushing calendar event messages from a host system to a mobile data communication device |
| US8516055B2 (en) | 1998-05-29 | 2013-08-20 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device in a wireless data network |
| US6219694B1 (en) | 1998-05-29 | 2001-04-17 | Research In Motion Limited | System and method for pushing information from a host system to a mobile data communication device having a shared electronic address |
| US9374435B2 (en) | 1998-05-29 | 2016-06-21 | Blackberry Limited | System and method for using trigger events and a redirector flag to redirect messages |
| US7209949B2 (en) | 1998-05-29 | 2007-04-24 | Research In Motion Limited | System and method for synchronizing information between a host system and a mobile data communication device |
| US6324645B1 (en) * | 1998-08-11 | 2001-11-27 | Verisign, Inc. | Risk management for public key management infrastructure using digital certificates |
| JP3754565B2 (en) * | 1998-10-30 | 2006-03-15 | 株式会社日立製作所 | Electronic seal mark authentication system |
| KR100484209B1 (en) * | 1998-09-24 | 2005-09-30 | 삼성전자주식회사 | Digital Content Encryption / Decryption Device and Method |
| US7499551B1 (en) * | 1999-05-14 | 2009-03-03 | Dell Products L.P. | Public key infrastructure utilizing master key encryption |
| US6772331B1 (en) * | 1999-05-21 | 2004-08-03 | International Business Machines Corporation | Method and apparatus for exclusively pairing wireless devices |
| US6988199B2 (en) * | 2000-07-07 | 2006-01-17 | Message Secure | Secure and reliable document delivery |
| US20020019932A1 (en) * | 1999-06-10 | 2002-02-14 | Eng-Whatt Toh | Cryptographically secure network |
| US20020101998A1 (en) * | 1999-06-10 | 2002-08-01 | Chee-Hong Wong | Fast escrow delivery |
| KR20010004791A (en) * | 1999-06-29 | 2001-01-15 | 윤종용 | Apparatus for securing user's informaton and method thereof in mobile communication system connecting with internet |
| US6367010B1 (en) | 1999-07-02 | 2002-04-02 | Postx Corporation | Method for generating secure symmetric encryption and decryption |
| US7966372B1 (en) | 1999-07-28 | 2011-06-21 | Rpost International Limited | System and method for verifying delivery and integrity of electronic messages |
| US7391865B2 (en) | 1999-09-20 | 2008-06-24 | Security First Corporation | Secure data parser method and system |
| KR100449423B1 (en) * | 1999-12-24 | 2004-09-21 | 한국전자통신연구원 | Association Establishment Scheme and Method for Number Portability |
| AU2000243591A1 (en) * | 2000-01-14 | 2001-07-24 | Critical Path Inc. | Secure management of electronic documents in a networked environment |
| US7685423B1 (en) * | 2000-02-15 | 2010-03-23 | Silverbrook Research Pty Ltd | Validation protocol and system |
| US7325127B2 (en) * | 2000-04-25 | 2008-01-29 | Secure Data In Motion, Inc. | Security server system |
| US7277549B2 (en) * | 2000-04-25 | 2007-10-02 | Secure Data In Motion, Inc. | System for implementing business processes using key server events |
| US7376835B2 (en) * | 2000-04-25 | 2008-05-20 | Secure Data In Motion, Inc. | Implementing nonrepudiation and audit using authentication assertions and key servers |
| US7076468B2 (en) * | 2000-04-28 | 2006-07-11 | Hillegass James C | Method and system for licensing digital works |
| US20020007351A1 (en) * | 2000-04-28 | 2002-01-17 | Hillegass James C. | Digital tokens and system and method relating to digital tokens |
| US6386894B2 (en) | 2000-04-28 | 2002-05-14 | Texas Instruments Incorporated | Versatile interconnection scheme for beverage quality and control sensors |
| US20020003886A1 (en) * | 2000-04-28 | 2002-01-10 | Hillegass James C. | Method and system for storing multiple media tracks in a single, multiply encrypted computer file |
| US7251728B2 (en) | 2000-07-07 | 2007-07-31 | Message Secure Corporation | Secure and reliable document delivery using routing lists |
| CA2418740C (en) * | 2000-08-08 | 2010-07-27 | Wachovia Corporation | Internet third-party authentication using electronic tickets |
| KR20020020133A (en) * | 2000-09-08 | 2002-03-14 | 정규석 | PKI system for and method of using WAP browser on mobile terminals |
| US6990654B2 (en) * | 2000-09-14 | 2006-01-24 | Bea Systems, Inc. | XML-based graphical user interface application development toolkit |
| AU2001293598A1 (en) * | 2000-10-05 | 2002-04-15 | Certicom Corp. | A method for providing information security for wireless transmissions |
| US20020048372A1 (en) * | 2000-10-19 | 2002-04-25 | Eng-Whatt Toh | Universal signature object for digital data |
| GB0027280D0 (en) * | 2000-11-08 | 2000-12-27 | Malcolm Peter | An information management system |
| US7082536B2 (en) | 2000-11-13 | 2006-07-25 | Globalcerts, Lc | System and method for computerized global messaging encryption |
| US20030046395A1 (en) * | 2000-12-12 | 2003-03-06 | Robert Fleming | System and method for bounding the life of an event subscription to the availability of an object |
| US7010303B2 (en) | 2000-12-22 | 2006-03-07 | Research In Motion Limited | Wireless router system and method |
| CA2368404C (en) | 2001-01-18 | 2005-08-09 | Research In Motion Limited | Unified messaging system and method |
| US6904521B1 (en) * | 2001-02-16 | 2005-06-07 | Networks Associates Technology, Inc. | Non-repudiation of e-mail messages |
| WO2002069087A2 (en) * | 2001-02-22 | 2002-09-06 | Bea Systems, Inc. | System and method for message encryption and signing in a transaction processing system |
| US8406389B2 (en) | 2001-03-09 | 2013-03-26 | Research In Motion Limited | Advanced voice and data operations in a mobile data communication device |
| CA2375844C (en) * | 2001-03-09 | 2008-12-30 | Research In Motion Limited | Advanced voice and data operations in a mobile data communication device |
| WO2002084590A1 (en) * | 2001-04-11 | 2002-10-24 | Applied Minds, Inc. | Knowledge web |
| EP1391073B8 (en) * | 2001-05-01 | 2018-09-05 | OneSpan International GmbH | Method and system for increasing security of a secure connection |
| US7359882B2 (en) * | 2001-05-11 | 2008-04-15 | Bea Systems, Inc. | Distributed run-time licensing |
| US7185105B2 (en) * | 2001-05-11 | 2007-02-27 | Bea Systems, Inc. | Application messaging system with flexible message header structure |
| EP1410296A2 (en) | 2001-06-12 | 2004-04-21 | Research In Motion Limited | Method for processing encoded messages for exchange with a mobile data communication device |
| CA2450601C (en) | 2001-06-12 | 2012-10-16 | Research In Motion Limited | System and method for compressing secure e-mail for exchange with a mobile data communication device |
| IL159342A0 (en) | 2001-06-12 | 2004-06-01 | Research In Motion Ltd | Certificate management and transfer system and method |
| US7016499B2 (en) * | 2001-06-13 | 2006-03-21 | Sun Microsystems, Inc. | Secure ephemeral decryptability |
| US9628269B2 (en) * | 2001-07-10 | 2017-04-18 | Blackberry Limited | System and method for secure message key caching in a mobile communication device |
| BRPI0211756B1 (en) | 2001-08-06 | 2016-09-06 | Blackberry Ltd | system and method for processing encrypted messages |
| US7317699B2 (en) | 2001-10-26 | 2008-01-08 | Research In Motion Limited | System and method for controlling configuration settings for mobile communication devices and services |
| US7305556B2 (en) * | 2001-12-05 | 2007-12-04 | Canon Kabushiki Kaisha | Secure printing with authenticated printer key |
| US7146009B2 (en) * | 2002-02-05 | 2006-12-05 | Surety, Llc | Secure electronic messaging system requiring key retrieval for deriving decryption keys |
| US20030196094A1 (en) * | 2002-04-10 | 2003-10-16 | Hillis W. Daniel | Method and apparatus for authenticating the content of a distributed database |
| US8069175B2 (en) | 2002-04-10 | 2011-11-29 | Google Inc. | Delegating authority to evaluate content |
| US7844610B2 (en) | 2003-12-12 | 2010-11-30 | Google Inc. | Delegated authority evaluation system |
| AU2003237252A1 (en) * | 2002-06-06 | 2003-12-22 | Thomson Licensing S.A. | Broker-based interworking using hierarchical certificates |
| US7822816B2 (en) * | 2002-08-19 | 2010-10-26 | Macrosolve, Inc. | System and method for data management |
| KR100995439B1 (en) * | 2002-09-28 | 2010-11-18 | 주식회사 케이티 | Streaming security system using the Streaming data security apparatus and method |
| US20040148356A1 (en) * | 2002-11-04 | 2004-07-29 | Bishop James William | System and method for private messaging |
| AU2003278331A1 (en) * | 2002-12-02 | 2004-06-23 | Alcatel | Games console adaptor unit |
| US8012025B2 (en) * | 2002-12-13 | 2011-09-06 | Applied Minds, Llc | Video game controller hub with control input reduction and combination schemes |
| US7765206B2 (en) | 2002-12-13 | 2010-07-27 | Metaweb Technologies, Inc. | Meta-Web |
| US7783044B2 (en) * | 2003-02-20 | 2010-08-24 | Proofpoint, Inc. | System for on-line and off-line decryption |
| WO2004111790A2 (en) * | 2003-06-11 | 2004-12-23 | Autouptodate Llc D/B/A Armorpost | Private messaging using independent and interoperating couriers |
| US7499548B2 (en) * | 2003-06-24 | 2009-03-03 | Intel Corporation | Terminal authentication in a wireless network |
| US7302565B2 (en) * | 2003-06-24 | 2007-11-27 | Arraycomm Llc | Terminal identity masking in a wireless network |
| US7409545B2 (en) | 2003-09-18 | 2008-08-05 | Sun Microsystems, Inc. | Ephemeral decryption utilizing binding functions |
| US7363499B2 (en) | 2003-09-18 | 2008-04-22 | Sun Microsystems, Inc. | Blinded encryption and decryption |
| US20050131918A1 (en) * | 2003-12-12 | 2005-06-16 | W. Daniel Hillis | Personalized profile for evaluating content |
| CN1998181B (en) * | 2004-01-09 | 2012-01-04 | 科尔街有限公司 | Batch OCSP and batch distributed OCSP |
| GB0411560D0 (en) * | 2004-05-24 | 2004-06-23 | Protx Group Ltd | A method of encrypting and transferring data between a sender and a receiver using a network |
| US9094429B2 (en) | 2004-08-10 | 2015-07-28 | Blackberry Limited | Server verification of secure electronic messages |
| US7509120B2 (en) * | 2004-09-07 | 2009-03-24 | Research In Motion Limited | System and method for updating message trust status |
| WO2006047694A1 (en) | 2004-10-25 | 2006-05-04 | Orsini Rick L | Secure data parser method and system |
| CA2606193C (en) | 2005-04-18 | 2015-03-17 | Research In Motion Limited | Method for providing wireless application privilege management |
| WO2007035655A2 (en) * | 2005-09-16 | 2007-03-29 | The Trustees Of Columbia University In The City Of New York | Using overlay networks to counter denial-of-service attacks |
| US7953971B2 (en) | 2005-10-27 | 2011-05-31 | Research In Motion Limited | Synchronizing certificates between a device and server |
| US8191105B2 (en) | 2005-11-18 | 2012-05-29 | Research In Motion Limited | System and method for handling electronic messages |
| CN105978683A (en) | 2005-11-18 | 2016-09-28 | 安全第公司 | Secure data parser method and system |
| US7840207B2 (en) | 2005-11-30 | 2010-11-23 | Research In Motion Limited | Display of secure messages on a mobile communication device |
| US8355701B2 (en) | 2005-11-30 | 2013-01-15 | Research In Motion Limited | Display of secure messages on a mobile communication device |
| US7574479B2 (en) * | 2006-01-24 | 2009-08-11 | Novell, Inc. | Techniques for attesting to content |
| US8059817B2 (en) * | 2006-06-20 | 2011-11-15 | Motorola Solutions, Inc. | Method and apparatus for encrypted communications using IPsec keys |
| US7814161B2 (en) | 2006-06-23 | 2010-10-12 | Research In Motion Limited | System and method for handling electronic mail mismatches |
| US20080167888A1 (en) * | 2007-01-09 | 2008-07-10 | I4 Commerce Inc. | Method and system for identification verification between at least a pair of entities |
| US8179872B2 (en) | 2007-05-09 | 2012-05-15 | Research In Motion Limited | Wireless router system and method |
| US10055595B2 (en) | 2007-08-30 | 2018-08-21 | Baimmt, Llc | Secure credentials control method |
| US7949355B2 (en) | 2007-09-04 | 2011-05-24 | Research In Motion Limited | System and method for processing attachments to messages sent to a mobile device |
| US8254582B2 (en) | 2007-09-24 | 2012-08-28 | Research In Motion Limited | System and method for controlling message attachment handling functions on a mobile device |
| US8379867B2 (en) * | 2007-09-24 | 2013-02-19 | Mymail Technology, Llc | Secure email communication system |
| KR100870202B1 (en) | 2007-11-22 | 2008-12-09 | 주식회사 오엘콥스 | Method and system of issuing accredited certificate using encrypted image |
| KR20100133953A (en) | 2007-12-21 | 2010-12-22 | 코쿤 데이터 홀딩스 리미티드 | System and method for securing data |
| US8286171B2 (en) | 2008-07-21 | 2012-10-09 | Workshare Technology, Inc. | Methods and systems to fingerprint textual information using word runs |
| US20100205429A1 (en) * | 2009-02-10 | 2010-08-12 | Gm Global Technology Operations, Inc. | System and method for verifying that a remote device is a trusted entity |
| US20110066843A1 (en) * | 2009-09-16 | 2011-03-17 | Brent Newman | Mobile media play system and method |
| CA2781872A1 (en) | 2009-11-25 | 2011-06-09 | Security First Corp. | Systems and methods for securing data in motion |
| US9443097B2 (en) | 2010-03-31 | 2016-09-13 | Security First Corp. | Systems and methods for securing data in motion |
| WO2011150346A2 (en) | 2010-05-28 | 2011-12-01 | Laurich Lawrence A | Accelerator system for use with secure data storage |
| CN101883096B (en) * | 2010-06-07 | 2014-07-02 | 天地融科技股份有限公司 | Method, device and system for safely transferring data between electronic signature tools |
| CN105071936B (en) | 2010-09-20 | 2018-10-12 | 安全第一公司 | The system and method shared for secure data |
| US8924715B2 (en) | 2010-10-28 | 2014-12-30 | Stephan V. Schell | Methods and apparatus for storage and execution of access control clients |
| US8635295B2 (en) | 2010-11-29 | 2014-01-21 | Workshare Technology, Inc. | Methods and systems for monitoring documents exchanged over email applications |
| US10783326B2 (en) | 2013-03-14 | 2020-09-22 | Workshare, Ltd. | System for tracking changes in a collaborative document editing environment |
| US9137214B2 (en) * | 2010-12-15 | 2015-09-15 | Microsoft Technology Licensing, Llc | Encrypted content streaming |
| US9613340B2 (en) | 2011-06-14 | 2017-04-04 | Workshare Ltd. | Method and system for shared document approval |
| US8732462B2 (en) * | 2011-07-07 | 2014-05-20 | Ziptr, Inc. | Methods and apparatus for secure data sharing |
| US20130145483A1 (en) * | 2011-12-02 | 2013-06-06 | Jpmorgan Chase Bank, N.A. | System And Method For Processing Protected Electronic Communications |
| US8249230B1 (en) | 2012-01-09 | 2012-08-21 | EC Data Systems, Inc. | Scalable and flexible internet fax architecture |
| US9285981B1 (en) | 2012-07-16 | 2016-03-15 | Wickr Inc. | Discouraging screen capture |
| US8762712B1 (en) * | 2012-07-27 | 2014-06-24 | Trend Micro Incorporated | Methods and system for person-to-person secure file transfer |
| JP2014053797A (en) * | 2012-09-07 | 2014-03-20 | Toshiba Corp | Device and program for electronic document management |
| WO2014059136A2 (en) * | 2012-10-12 | 2014-04-17 | Safelylocked, Llc. | Techniqued for secure data exchange |
| US9881177B2 (en) | 2013-02-13 | 2018-01-30 | Security First Corp. | Systems and methods for a cryptographic file system layer |
| US9767299B2 (en) | 2013-03-15 | 2017-09-19 | Mymail Technology, Llc | Secure cloud data sharing |
| CN105164968A (en) * | 2013-04-25 | 2015-12-16 | 瑞保企业 | Method performed by at least one server for processing a data packet from a first computing device to a second computing device to permit end-to-end encryption communication |
| US10129260B1 (en) | 2013-06-25 | 2018-11-13 | Wickr Inc. | Mutual privacy management |
| US9866591B1 (en) | 2013-06-25 | 2018-01-09 | Wickr Inc. | Enterprise messaging platform |
| US9830089B1 (en) | 2013-06-25 | 2017-11-28 | Wickr Inc. | Digital data sanitization |
| US10567349B2 (en) | 2013-06-25 | 2020-02-18 | Wickr Inc. | Secure time-to-live |
| CN106170944B (en) * | 2014-01-31 | 2019-11-26 | 快普特奥姆特里有限公司 | Ensure method, the safety communications equipment, public key server of system communication safety |
| US9698976B1 (en) | 2014-02-24 | 2017-07-04 | Wickr Inc. | Key management and dynamic perfect forward secrecy |
| US10277778B2 (en) | 2014-06-24 | 2019-04-30 | Ec Data Systems Inc. | Audit logging for a secure, scalable and flexible internet fax architecture |
| US9584530B1 (en) | 2014-06-27 | 2017-02-28 | Wickr Inc. | In-band identity verification and man-in-the-middle defense |
| US10031679B2 (en) | 2014-11-21 | 2018-07-24 | Security First Corp. | Gateway for cloud-based secure storage |
| US9654288B1 (en) | 2014-12-11 | 2017-05-16 | Wickr Inc. | Securing group communications |
| US9584493B1 (en) | 2015-12-18 | 2017-02-28 | Wickr Inc. | Decentralized authoritative messaging |
| US10291607B1 (en) | 2016-02-02 | 2019-05-14 | Wickr Inc. | Providing real-time events to applications |
| US9591479B1 (en) | 2016-04-14 | 2017-03-07 | Wickr Inc. | Secure telecommunications |
| US9590958B1 (en) | 2016-04-14 | 2017-03-07 | Wickr Inc. | Secure file transfer |
| US10560263B2 (en) * | 2017-03-24 | 2020-02-11 | Micron Technology, Inc. | Secure memory arrangements |
| US11140173B2 (en) | 2017-03-31 | 2021-10-05 | Baimmt, Llc | System and method for secure access control |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5283832A (en) * | 1991-10-22 | 1994-02-01 | Motorola, Inc. | Paging message encryption |
| JP2659896B2 (en) * | 1992-04-29 | 1997-09-30 | インターナショナル・ビジネス・マシーンズ・コーポレイション | Structured document copy management method and structured document copy management device |
| JPH06223041A (en) * | 1993-01-22 | 1994-08-12 | Fujitsu Ltd | Rarge-area environment user certification system |
| US5420927B1 (en) * | 1994-02-01 | 1997-02-04 | Silvio Micali | Method for certifying public keys in a digital signature scheme |
| US5588060A (en) * | 1994-06-10 | 1996-12-24 | Sun Microsystems, Inc. | Method and apparatus for a key-management scheme for internet protocols |
| US5606617A (en) * | 1994-10-14 | 1997-02-25 | Brands; Stefanus A. | Secret-key certificates |
| US5604804A (en) * | 1996-04-23 | 1997-02-18 | Micali; Silvio | Method for certifying public keys in a digital signature scheme |
| US5751813A (en) * | 1996-04-29 | 1998-05-12 | Motorola, Inc. | Use of an encryption server for encrypting messages |
| US5812671A (en) * | 1996-07-17 | 1998-09-22 | Xante Corporation | Cryptographic communication system |
-
1997
- 1997-01-31 US US08/791,968 patent/US6009173A/en not_active Expired - Lifetime
-
1998
- 1998-01-09 CA CA002278670A patent/CA2278670C/en not_active Expired - Fee Related
- 1998-01-09 EP EP98909972A patent/EP0962072A4/en not_active Withdrawn
- 1998-01-09 CN CNB988028395A patent/CN1155198C/en not_active Expired - Fee Related
- 1998-01-09 WO PCT/US1998/000291 patent/WO1998034374A1/en not_active Application Discontinuation
- 1998-01-09 KR KR10-1999-7006872A patent/KR100380125B1/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| EP0962072A1 (en) | 1999-12-08 |
| US6009173A (en) | 1999-12-28 |
| CA2278670A1 (en) | 1998-08-06 |
| WO1998034374A1 (en) | 1998-08-06 |
| EP0962072A4 (en) | 2002-09-04 |
| CN1155198C (en) | 2004-06-23 |
| KR20000070624A (en) | 2000-11-25 |
| KR100380125B1 (en) | 2003-04-16 |
| CN1249096A (en) | 2000-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2278670C (en) | Encryption and decryption method and apparatus | |
| US6567914B1 (en) | Apparatus and method for reducing transmission bandwidth and storage requirements in a cryptographic security system | |
| US6912285B2 (en) | Mechanism for efficient private bulk messaging | |
| US6341164B1 (en) | Method and apparatus for correcting improper encryption and/or for reducing memory storage | |
| US6061448A (en) | Method and system for dynamic server document encryption | |
| JP5204090B2 (en) | Communication network, e-mail registration server, network device, method, and computer program | |
| US6851049B1 (en) | Method and apparatus for facilitating secure anonymous email recipients | |
| US20020138759A1 (en) | System and method for secure delivery of a parcel or document | |
| US20020172367A1 (en) | System for secure electronic information transmission | |
| Schaad et al. | Secure/multipurpose internet mail extensions (S/MIME) version 4.0 message specification | |
| US20040236953A1 (en) | Method and device for transmitting an electronic message | |
| WO1999034553A1 (en) | Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network | |
| JPH10105057A (en) | Time stamp server system | |
| US7031469B2 (en) | Optimized enveloping via key reuse | |
| JPH0969831A (en) | Cipher communication system | |
| JP2000183866A (en) | Method and system for cipher communication, and recording medium stored with cipher communication program | |
| JP3563649B2 (en) | Communication control device and recording medium | |
| Housley | RFC2630: Cryptographic Message Syntax | |
| CN114172694A (en) | E-mail encryption and decryption method, system and storage medium | |
| JP4034946B2 (en) | COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND RECORDING MEDIUM | |
| KR100432611B1 (en) | System for providing service to transmit and receive document based on e-mail system and method thereof | |
| JP3796528B2 (en) | Communication system for performing content certification and content certification site device | |
| JP3725020B2 (en) | Electronic data content certification method and system | |
| CN113014531B (en) | Method for encrypting and transmitting e-mail data | |
| CN115765973A (en) | Encryption tagging multiplexing architecture method based on financial scene |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |