US20040010684A1 - Method and system for the exchange of digitally signed objects over an insecure network - Google Patents
Method and system for the exchange of digitally signed objects over an insecure network Download PDFInfo
- Publication number
- US20040010684A1 US20040010684A1 US09/095,453 US9545398A US2004010684A1 US 20040010684 A1 US20040010684 A1 US 20040010684A1 US 9545398 A US9545398 A US 9545398A US 2004010684 A1 US2004010684 A1 US 2004010684A1
- Authority
- US
- United States
- Prior art keywords
- signed
- signed object
- sequence number
- signature
- computer system
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 238000004891 communication Methods 0.000 claims abstract description 38
- 238000012795 verification Methods 0.000 claims description 12
- 238000010586 diagram Methods 0.000 description 12
- 230000015572 biosynthetic process Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000013478 data encryption standard Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000010276 construction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
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/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
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
Definitions
- the present invention relates to network communication, and more particularly to authenticated communication across an insecure network.
- Encryption suitably refers to the transformation of plaintext data into an unintelligible form known as ciphertext. Encryption is usually accomplished by the application of mathematical algorithms on the plaintext data. These algorithms are defined by parameters known as ‘keys’. Two common encryption methods are symmetric methods which use private keys, and asymmetric methods which use public keys. Both private key encryption (such as DES (Data Encryption Standard)) and public key encryption methods have been implemented, but, key cryptographic methods alone do not allow a recipient to authenticate the validity of the public key nor to validate the identity of the sender.
- DES Data Encryption Standard
- authentication allows for the verification that someone or something is valid or genuine.
- Digital signature authentication allows the receiver of a message to be confident of the identity of the sender and/or the integrity of the message.
- Digital signatures have been used to guarantee the validity of a public key by being incorporated into a digital certificate.
- the ‘signed’ document containing the digital signature attests to the validity and public key of the person signing the message, and prevents one user from impersonating another through a phony key pair.
- the certificate also contains the validity period of the key, the name of the issuer of the certificate, the certificate serial number, and is digitally signed by the issuer.
- a secure, centralized repository is required for storing and managing the keys.
- the X.500 directory may be used as a repository for storing certificates, with association of the public keys of network users with their distinguished name.
- An X.500 distinguished name refers to a unique object in the X.500 Directory, and is a sequence of vertex points leading from the ‘root’ of the tree to the object of interest, as is conventionally understood).
- the X.500 standard defines an authentication framework, known as X.509, for use by OSI (Open Systems International connection) applications to provide a basis for authentication and security services.
- the X.509 framework describes how authentication information is formed and placed in the directory.
- the X.509 authentication framework also defines basic security services, including simple and strong authentication. Strong authentication involves the use of public key cryptographic standard (PKCS) and a trusted hierarchy of Certificate Authorities (CAs), where a CA refers to a trusted source for obtaining a user's authentication information or certificate.
- PKCS public key cryptographic standard
- CAs Certificate Authority
- the present invention provides method and system aspects for authenticated communication of messages among computer systems in an insecure network. These aspects include building a first signed object message in a first computer system, the first signed object message including a first sequence number, a first object, and a first signature. Further included is sending the first signed object message to a second computer system, verifying the first signed object message in the second computer system, and building a second signed object message in the second computer system for replying to the first computer system when the first signed object message is verified, the second signed object message including a second sequence number, a second object, and a second signature.
- FIG. 1 illustrates a functional block diagram of a computer network in accordance with the present invention.
- FIG. 2 illustrates a block diagram of a computer in the network of FIG. 1.
- FIG. 3 illustrates a block diagram of a process for formation of a signed object message in accordance with the present invention.
- FIG. 4 illustrates an exemplary class hierarchy diagram of a signed object socket.
- FIG. 5 illustrates an exemplary class hierarchy diagram of the serializable stream of signed object data from a signed object socket.
- FIG. 6 illustrates an example of suitable signature creation logic.
- FIG. 7 illustrates an example of suitable signature verification logic.
- FIG. 8 illustrates a block diagram of a handshake for signed object communication in accordance with the present invention.
- the present invention relates to authenticated communication over an insecure network.
- the following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements.
- Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments.
- the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
- the present invention is described in a preferred embodiment as being implemented in accordance with Java object-oriented programming techniques, and more specifically, with resources of the Java Development Kit (JDK) 1.1, available from Sun Microsystems, Inc., Mountain View, Calif.
- JDK Java Development Kit
- the aspects of the present invention may be achieved in other programming environments that provide substantially equivalent functionality, as is well appreciated by those skilled in the art.
- FIG. 1 illustrates a functional block diagram of a computer network arrangement 10 with authenticated channel operations between Java applications in accordance with the present invention.
- computer network 10 includes a plurality of computers 12 ( 1 ) through 12 (N) (generally referred to herein as 12 ) interconnected by a communication link 14 .
- computers 12 are in the form of personal computers or computer workstations, each of which includes a system unit, a video display unit, and operator input devices, such as a keyboard and mouse, as is conventionally known.
- the system unit generally includes processing, memory, and mass storage devices, such as disk and/or tape storage elements, and other elements (not separately shown), including network interface devices 18 for interfacing the computers 12 to the communication link 14 .
- a video display unit permits the computer to display processed data and processing status to the user, and an operator input device enables the user to input data and control processing by the computer.
- the computers 12 transfer information, in the form of messages, through their respective network devices 18 among each other over the communication link 14 .
- the network 10 is suitably organized in a conventional ‘client-server’ configuration, in which various ones of the computers 12 act as clients and servers.
- the communication link 14 interconnecting the clients 12 in the network 10 may, as is conventional, comprise wires, optical fibers, or other suitable media for carrying signals representing information among the computers 12 .
- the computer link 14 may comprise a public telephony system and/or the Internet, over which a person using computer 12 may access information, including programs and data from a ‘server’ computer which may be located some distance from a ‘client’ computer, as is well understood by those skilled in the art.
- digitally authenticated communication between Java applications operating on computers 12 via communication link 14 is achieved.
- each of the computers 12 includes two ports, a registration/discovery port 20 and an object port 22 , as shown in FIG. 2.
- the registration/discovery port 22 is suitably utilized in identifying network participants, the operation of which is not included in the discussion of the present invention.
- communication over the object port 22 utilizes a digitally signed exchange of objects using object serialization and DSA (digital signature algorithm) signatures.
- object serialization and DSA digital signature algorithm
- FIG. 3 illustrates a block diagram of a process for formation of a signed object in accordance with the present invention, the process being provided via a suitable computer readable medium, e.g., computer memory, floppy disk, hard disk, etc.
- a signed object refers to an object message signed using DSS (digital signature standard) to generate signature bits based on the serialized version of the object and sequence number.
- an application 30 i.e., a Java application
- client FIG. 1
- a socket e.g., a SignedObjectSocket, 34 is provided in accordance with the present invention and formed as a specialized java.net.socket for facilitating the formation of a signed object 36 .
- the signed object 36 is suitably associated with an object context, e.g., an ObjectSigning context, 38 in accordance with the message exchange protocol of the present invention.
- the signed object 36 includes a signature 40 and a sequence number (seq#) 42 attached to the original object 32 .
- the signed object 36 is then appropriately communicated over communication link 14 via a server socket 44 , e.g., a TCP/IP socket.
- a server socket 44 e.g., a TCP/IP socket.
- FIG. 4 illustrates an exemplary class hierarchy diagram for signed object socket 34 .
- signed object socket 34 is suitably a subclass of the socket class 46 (from java.net).
- object context ObjectSigningContext, 38 , which is a subclass of a cloneable class 50 (from java.lang).
- signed object server subclass 52 of a server socket class 54 from java.net.
- logger 56 for logging signature handshake failures, signature handshake failures occurring during a handshake, the handshake being described more fully hereinbelow.
- FIG. 5 illustrates an exemplary class hierarchy diagram for the serializable stream of signed object data from signed object socket 34 .
- the signed object socket 34 returns an input stream 58 or an output stream 60 (from java.io) depending upon whether the computer 12 is sending or receiving an object message.
- the input and output stream objects 58 and 60 are of a signed object input stream class 62 and signed object output stream class 64 , respectively.
- the signed object output stream 64 creates a signed object 66 (which is a subclass of a serializable class 68 from java.io) internally composed of the object written, a sequence number, and a signature comprising the serializable object and the sequence number, which is written to the output.
- the signed object input stream 62 reads a signed object 66 , verifies the signature and passes along the inner object to the caller.
- the signed object is signed using an object signing context ( 38 , FIG. 3).
- An example of suitable signature creation logic 70 in accordance with the present invention is presented in FIG. 6.
- the logic of FIG. 6 represent construction of a DER (distinguished encoding rule) sequence with the outgoing sequence number as a big integer (BigInt) followed by the serializable object.
- the DER encoded sequence is then signed using the signer object ( 38 a , FIG. 3) in the object context with the signature bits stored in the signed object ( 36 , FIG. 3).
- the signature of the signed object requires verification.
- An example of signature verification logic 72 is presented in the diagram of FIG. 7. Verification occurs by first reconstructing the DER encoded sequence and verifying the signature bits stored in the signed object using the public key from the object signing context on the recipient's side. As described above, the establishment of signature verification through signed objects initiates via a pair of handshake messages.
- FIG. 8 illustrates a diagram of a process for a handshake between two computers 12 , one computer acting as client A and a second computer acting as server B.
- the initial handshake in setting up the signed object communication consists of a pair of messages exchanged between the sender (client A) and the receiver (server B).
- the messages exchanged serve to authenticate the communication and to prime the object context with the certificate and incoming sequence number.
- the handshake begins with the communication initiator, i.e., client A, building a signed object handshake message 74 , SignedObjectHandshakeMessage, with its certificate 76 and a chosen sequence number 78 in accordance with its object context 80 .
- the chosen sequence number preferably provides a number that prevents replay attacks, such as a random number or the current timestamp represented as a long.
- the certificate requires previous generation and distribution, such as by the certificate generation method provided in co-pending U.S. patent application, entitled “Method and System for Digital Certificate Generation and Distribution”, Ser. No. ______ (unknown), (attorney docket SA998028/JAS970P) assigned to the assignee of the present invention, incorporated herein by reference in its entirety. Other certificate forming methods, may be used if desired without departing from the spirit and scope of the present invention.
- the signed object 74 further includes signature 82 generated in accordance with the signature generation logic presented above.
- a SignedObjectHandshakeMessage constructor suitably packages the certificate and incoming sequence number as a Vector which becomes the object to be signed.
- the client A signs the message using zero as the outgoing sequence number and sends the message across the channel via socket 44 (FIG. 3).
- the communication receiver, server B receives the initial message and uses it to construct its ObjectSigningContext 84 .
- the certificate of client A is suitably verified as either being one in a store on server B or being signed by a certificate server B knows about, as is well understood by those skilled in the art.
- a strict attribute (shown in object context 48 , FIG. 5) of the object context 84 where true means that the certificate must be in the store already, provides capable control of the verification.
- server B builds its own signed object to complete the handshake, e.g., a SignedObjectHandshakeMessage object 86 , using its certificate 88 and another randomly chosen sequence number 90 , represented as ‘m’.
- Server B also completes the initialization of its local ObjectSigningContext 84 with the partner certificate provided by client A (A's cert) and the outgoing sequence number (n+1).
- the signed object 86 formed includes server B's signature 94 , outgoing sequence number 92 , and an object comprising its sequence number ‘m’ 90 and certificate 88 .
- client A receives the signed object handshake message 86 from server B
- client A completes its initialization of object context 80 , verifies server B's certificate 88 based on the strict attribute, and verifies the signed object handshake message 86 received.
- signed object message exchange continues by incrementing sequence numbers, building signatures, and verifying each signed object message as it is received. If at any point during the communication the negotiation fails by either party, the socket connection is dropped.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
- The present invention relates to network communication, and more particularly to authenticated communication across an insecure network.
- Data communication across computer networks has become a standard in both professional and personal computing environments. With the increase in reliance on computer networks for data communication, increased efforts have arisen to ensure that networks remain secure during data transfers. More particularly, data encryption techniques have been developed and utilized to aid in securing data communication across networks.
- Encryption suitably refers to the transformation of plaintext data into an unintelligible form known as ciphertext. Encryption is usually accomplished by the application of mathematical algorithms on the plaintext data. These algorithms are defined by parameters known as ‘keys’. Two common encryption methods are symmetric methods which use private keys, and asymmetric methods which use public keys. Both private key encryption (such as DES (Data Encryption Standard)) and public key encryption methods have been implemented, but, key cryptographic methods alone do not allow a recipient to authenticate the validity of the public key nor to validate the identity of the sender.
- In general, authentication allows for the verification that someone or something is valid or genuine. Digital signature authentication allows the receiver of a message to be confident of the identity of the sender and/or the integrity of the message. Digital signatures have been used to guarantee the validity of a public key by being incorporated into a digital certificate. The ‘signed’ document containing the digital signature attests to the validity and public key of the person signing the message, and prevents one user from impersonating another through a phony key pair. Along with the public key and name of the subject, the certificate also contains the validity period of the key, the name of the issuer of the certificate, the certificate serial number, and is digitally signed by the issuer. However, a secure, centralized repository is required for storing and managing the keys. For example, the X.500 directory may be used as a repository for storing certificates, with association of the public keys of network users with their distinguished name. (An X.500 distinguished name refers to a unique object in the X.500 Directory, and is a sequence of vertex points leading from the ‘root’ of the tree to the object of interest, as is conventionally understood). The X.500 standard defines an authentication framework, known as X.509, for use by OSI (Open Systems International connection) applications to provide a basis for authentication and security services. The X.509 framework describes how authentication information is formed and placed in the directory. The X.509 authentication framework also defines basic security services, including simple and strong authentication. Strong authentication involves the use of public key cryptographic standard (PKCS) and a trusted hierarchy of Certificate Authorities (CAs), where a CA refers to a trusted source for obtaining a user's authentication information or certificate.
- While data encryption techniques do provide security for network communications, such security measures are too extreme and costly to implement for some networks. For example, in certain situations, total data security is not as vital as verification that systems performing communication are authentic. A desire remains therefore for authenticated communication across an insecure network. In such situations, the concern is ensuring that the communicating system is genuine in its representation, rather than strict security of data.
- Accordingly, what is needed is a method and system for providing an authenticated communication channel in an efficient and effective manner. The present invention addresses such a need.
- The present invention provides method and system aspects for authenticated communication of messages among computer systems in an insecure network. These aspects include building a first signed object message in a first computer system, the first signed object message including a first sequence number, a first object, and a first signature. Further included is sending the first signed object message to a second computer system, verifying the first signed object message in the second computer system, and building a second signed object message in the second computer system for replying to the first computer system when the first signed object message is verified, the second signed object message including a second sequence number, a second object, and a second signature.
- Through the present invention, communication among computer systems in an insecure network readily occurs in an authenticated manner. Further, the signed object exchange utilizes available resources in an innovative and straightforward manner, while achieving communication techniques that are resistant to replay attacks and exportable. These and other advantages of the aspects of the present invention will be more fully understood in conjunction with the following detailed description and accompanying drawings.
- FIG. 1 illustrates a functional block diagram of a computer network in accordance with the present invention.
- FIG. 2 illustrates a block diagram of a computer in the network of FIG. 1.
- FIG. 3 illustrates a block diagram of a process for formation of a signed object message in accordance with the present invention.
- FIG. 4 illustrates an exemplary class hierarchy diagram of a signed object socket.
- FIG. 5 illustrates an exemplary class hierarchy diagram of the serializable stream of signed object data from a signed object socket.
- FIG. 6 illustrates an example of suitable signature creation logic.
- FIG. 7 illustrates an example of suitable signature verification logic.
- FIG. 8 illustrates a block diagram of a handshake for signed object communication in accordance with the present invention.
- The present invention relates to authenticated communication over an insecure network. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.
- Further, the present invention is described in a preferred embodiment as being implemented in accordance with Java object-oriented programming techniques, and more specifically, with resources of the Java Development Kit (JDK) 1.1, available from Sun Microsystems, Inc., Mountain View, Calif. However, it should be appreciated that the aspects of the present invention may be achieved in other programming environments that provide substantially equivalent functionality, as is well appreciated by those skilled in the art.
- FIG. 1 illustrates a functional block diagram of a
computer network arrangement 10 with authenticated channel operations between Java applications in accordance with the present invention. As shown in FIG. 1,computer network 10 includes a plurality of computers 12(1) through 12(N) (generally referred to herein as 12) interconnected by acommunication link 14. At least some of thecomputers 12 are in the form of personal computers or computer workstations, each of which includes a system unit, a video display unit, and operator input devices, such as a keyboard and mouse, as is conventionally known. The system unit generally includes processing, memory, and mass storage devices, such as disk and/or tape storage elements, and other elements (not separately shown), includingnetwork interface devices 18 for interfacing thecomputers 12 to thecommunication link 14. A video display unit permits the computer to display processed data and processing status to the user, and an operator input device enables the user to input data and control processing by the computer. Thecomputers 12 transfer information, in the form of messages, through theirrespective network devices 18 among each other over thecommunication link 14. - The
network 10 is suitably organized in a conventional ‘client-server’ configuration, in which various ones of thecomputers 12 act as clients and servers. Thecommunication link 14 interconnecting theclients 12 in thenetwork 10 may, as is conventional, comprise wires, optical fibers, or other suitable media for carrying signals representing information among thecomputers 12. In addition thecomputer link 14 may comprise a public telephony system and/or the Internet, over which aperson using computer 12 may access information, including programs and data from a ‘server’ computer which may be located some distance from a ‘client’ computer, as is well understood by those skilled in the art. Through the present invention, digitally authenticated communication between Java applications operating oncomputers 12 viacommunication link 14 is achieved. - In a preferred embodiment, each of the
computers 12 includes two ports, a registration/discovery port 20 and anobject port 22, as shown in FIG. 2. The registration/discovery port 22 is suitably utilized in identifying network participants, the operation of which is not included in the discussion of the present invention. In a preferred embodiment, communication over theobject port 22 utilizes a digitally signed exchange of objects using object serialization and DSA (digital signature algorithm) signatures. Thus, with theobject port 22, a customized protocol is provided that advantageously utilizes available resources of JDK 1.1. - In general terms, to clients and
servers 12 using theobject port 22 for communication, it appears that thecomputers 12 are reading and writing objects from a socket. At a lower level, the objects are signed on the sending side, and the signature is verified on the receiving side. Certificates are exchanged during the establishment of a socket connection in a handshake that validates the two communicating parties, as described more fully hereinbelow. - FIG. 3 illustrates a block diagram of a process for formation of a signed object in accordance with the present invention, the process being provided via a suitable computer readable medium, e.g., computer memory, floppy disk, hard disk, etc. For purposes of this discussion, a signed object refers to an object message signed using DSS (digital signature standard) to generate signature bits based on the serialized version of the object and sequence number. Referring to FIG. 3, an application30 (i.e., a Java application) operating on a ‘client’ 12 (FIG. 1) creates an
object 32 for communication. A socket, e.g., a SignedObjectSocket, 34 is provided in accordance with the present invention and formed as a specialized java.net.socket for facilitating the formation of a signedobject 36. The signedobject 36 is suitably associated with an object context, e.g., an ObjectSigning context, 38 in accordance with the message exchange protocol of the present invention. From theobject signing context 38, which provides a signer's keys 38 a, i.e., a public/private key pair used to sign, a signer's certificate 38 b which identifies the signer, apartner certificate 38 c identified by the system being communicated with, an outgoing sequence number 38 d (outGoingSeq#), and an incoming sequence number 38 e (inComingSeq#), the signedobject 36 includes a signature 40 and a sequence number (seq#) 42 attached to theoriginal object 32. The signedobject 36 is then appropriately communicated overcommunication link 14 via aserver socket 44, e.g., a TCP/IP socket. Thus, the entire SignedObject is sent across a TCP/IP socket using object serialization, constructed on the other end, and then verified. - FIG. 4 illustrates an exemplary class hierarchy diagram for signed
object socket 34. As shown, signedobject socket 34 is suitably a subclass of the socket class 46 (from java.net). Associated with the signedobject socket subclass 34 is the object context, ObjectSigningContext, 38, which is a subclass of a cloneable class 50 (from java.lang). Also included is a signed object server subclass 52 of a server socket class 54 (from java.net). Associated with the signed object server subclass 52 is alogger 56 for logging signature handshake failures, signature handshake failures occurring during a handshake, the handshake being described more fully hereinbelow. - FIG. 5 illustrates an exemplary class hierarchy diagram for the serializable stream of signed object data from signed
object socket 34. When requested, the signedobject socket 34 returns aninput stream 58 or an output stream 60 (from java.io) depending upon whether thecomputer 12 is sending or receiving an object message. The input and output stream objects 58 and 60 are of a signed object input stream class 62 and signed object output stream class 64, respectively. The signed object output stream 64 creates a signed object 66 (which is a subclass of a serializable class 68 from java.io) internally composed of the object written, a sequence number, and a signature comprising the serializable object and the sequence number, which is written to the output. The signed object input stream 62 reads a signed object 66, verifies the signature and passes along the inner object to the caller. - Preferably, the signed object is signed using an object signing context (38, FIG. 3). An example of suitable
signature creation logic 70 in accordance with the present invention is presented in FIG. 6. The logic of FIG. 6 represent construction of a DER (distinguished encoding rule) sequence with the outgoing sequence number as a big integer (BigInt) followed by the serializable object. The DER encoded sequence is then signed using the signer object (38 a, FIG. 3) in the object context with the signature bits stored in the signed object (36, FIG. 3). - Upon receiving a signed object, the signature of the signed object requires verification. An example of
signature verification logic 72 is presented in the diagram of FIG. 7. Verification occurs by first reconstructing the DER encoded sequence and verifying the signature bits stored in the signed object using the public key from the object signing context on the recipient's side. As described above, the establishment of signature verification through signed objects initiates via a pair of handshake messages. - FIG. 8 illustrates a diagram of a process for a handshake between two
computers 12, one computer acting as client A and a second computer acting as server B. The initial handshake in setting up the signed object communication consists of a pair of messages exchanged between the sender (client A) and the receiver (server B). The messages exchanged serve to authenticate the communication and to prime the object context with the certificate and incoming sequence number. The handshake begins with the communication initiator, i.e., client A, building a signedobject handshake message 74, SignedObjectHandshakeMessage, with itscertificate 76 and a chosen sequence number 78 in accordance with itsobject context 80. The chosen sequence number preferably provides a number that prevents replay attacks, such as a random number or the current timestamp represented as a long. The certificate requires previous generation and distribution, such as by the certificate generation method provided in co-pending U.S. patent application, entitled “Method and System for Digital Certificate Generation and Distribution”, Ser. No. ______ (unknown), (attorney docket SA998028/JAS970P) assigned to the assignee of the present invention, incorporated herein by reference in its entirety. Other certificate forming methods, may be used if desired without departing from the spirit and scope of the present invention. - The signed
object 74 further includes signature 82 generated in accordance with the signature generation logic presented above. A SignedObjectHandshakeMessage constructor suitably packages the certificate and incoming sequence number as a Vector which becomes the object to be signed. The client A signs the message using zero as the outgoing sequence number and sends the message across the channel via socket 44 (FIG. 3). - The communication receiver, server B, receives the initial message and uses it to construct its
ObjectSigningContext 84. The certificate of client A is suitably verified as either being one in a store on server B or being signed by a certificate server B knows about, as is well understood by those skilled in the art. A strict attribute (shown in object context 48, FIG. 5) of theobject context 84, where true means that the certificate must be in the store already, provides capable control of the verification. - If the signature is verified, server B builds its own signed object to complete the handshake, e.g., a
SignedObjectHandshakeMessage object 86, using its certificate 88 and another randomly chosen sequence number 90, represented as ‘m’. Server B also completes the initialization of itslocal ObjectSigningContext 84 with the partner certificate provided by client A (A's cert) and the outgoing sequence number (n+1). The signedobject 86 formed includes server B'ssignature 94, outgoing sequence number 92, and an object comprising its sequence number ‘m’ 90 and certificate 88. - Once client A receives the signed
object handshake message 86 from server B, client A completes its initialization ofobject context 80, verifies server B's certificate 88 based on the strict attribute, and verifies the signedobject handshake message 86 received. Once the initial handshake and verification are complete, signed object message exchange continues by incrementing sequence numbers, building signatures, and verifying each signed object message as it is received. If at any point during the communication the negotiation fails by either party, the socket connection is dropped. - Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. For example, although the computer systems are described as having separate registration/discovery and object ports, a communication scheme could be developed that would allow a single port to be used. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.
Claims (16)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/095,453 US6684332B1 (en) | 1998-06-10 | 1998-06-10 | Method and system for the exchange of digitally signed objects over an insecure network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/095,453 US6684332B1 (en) | 1998-06-10 | 1998-06-10 | Method and system for the exchange of digitally signed objects over an insecure network |
Publications (2)
Publication Number | Publication Date |
---|---|
US20040010684A1 true US20040010684A1 (en) | 2004-01-15 |
US6684332B1 US6684332B1 (en) | 2004-01-27 |
Family
ID=30113678
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/095,453 Expired - Fee Related US6684332B1 (en) | 1998-06-10 | 1998-06-10 | Method and system for the exchange of digitally signed objects over an insecure network |
Country Status (1)
Country | Link |
---|---|
US (1) | US6684332B1 (en) |
Cited By (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030097592A1 (en) * | 2001-10-23 | 2003-05-22 | Koteshwerrao Adusumilli | Mechanism supporting wired and wireless methods for client and server side authentication |
US20030236978A1 (en) * | 2002-06-24 | 2003-12-25 | Evans Glenn F. | Secure media path methods, systems, and architectures |
US20050091541A1 (en) * | 1999-03-27 | 2005-04-28 | Microsoft Corporation | Specifying security for an element by assigning a scaled value representative of the relative security thereof |
US20050223226A1 (en) * | 2004-04-02 | 2005-10-06 | Microsoft Corporation | Authenticated exchange of public information using electronic mail |
US20060235798A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Output protection levels |
US20060248594A1 (en) * | 2005-04-22 | 2006-11-02 | Microsoft Corporation | Protected media pipeline |
US20080021839A1 (en) * | 2000-01-14 | 2008-01-24 | Microsoft Corporation | Releasing decrypted digital content to an authenticated path |
US20080133523A1 (en) * | 2004-07-26 | 2008-06-05 | Sourcefire, Inc. | Methods and systems for multi-pattern searching |
US20080196102A1 (en) * | 2006-10-06 | 2008-08-14 | Sourcefire, Inc. | Device, system and method for use of micro-policies in intrusion detection/prevention |
US20080209518A1 (en) * | 2007-02-28 | 2008-08-28 | Sourcefire, Inc. | Device, system and method for timestamp analysis of segments in a transmission control protocol (TCP) session |
US20080215896A1 (en) * | 2003-02-25 | 2008-09-04 | Steve Bourne | Issuing a Publisher Use License Off-Line in a Digital Rights Management (DRM) System |
US20080244741A1 (en) * | 2005-11-14 | 2008-10-02 | Eric Gustafson | Intrusion event correlation with network discovery information |
US20080276319A1 (en) * | 2007-04-30 | 2008-11-06 | Sourcefire, Inc. | Real-time user awareness for a computer network |
US20090158036A1 (en) * | 2005-04-22 | 2009-06-18 | Microsoft Corporation | protected computing environment |
US20090262659A1 (en) * | 2008-04-17 | 2009-10-22 | Sourcefire, Inc. | Speed and memory optimization of intrusion detection system (IDS) and intrusion prevention system (IPS) rule processing |
US20100017615A1 (en) * | 2006-12-15 | 2010-01-21 | Boesgaard Soerensen Hans Martin | Digital data authentication |
US20100088767A1 (en) * | 2008-10-08 | 2010-04-08 | Sourcefire, Inc. | Target-based smb and dce/rpc processing for an intrusion detection system or intrusion prevention system |
US20100205675A1 (en) * | 2005-11-14 | 2010-08-12 | Sourcefire, Inc. | Systems and methods for modifying network map attributes |
US20100217985A1 (en) * | 2009-02-20 | 2010-08-26 | Comcast Cable Holdings, Llc | Authenticated Communication Between Security Devices |
US7801980B1 (en) | 2003-05-12 | 2010-09-21 | Sourcefire, Inc. | Systems and methods for determining characteristics of a network |
US7948988B2 (en) | 2006-07-27 | 2011-05-24 | Sourcefire, Inc. | Device, system and method for analysis of fragments in a fragment train |
US8020201B2 (en) | 2001-10-23 | 2011-09-13 | Intel Corporation | Selecting a security format conversion for wired and wireless devices |
US8433790B2 (en) | 2010-06-11 | 2013-04-30 | Sourcefire, Inc. | System and method for assigning network blocks to sensors |
US8601034B2 (en) | 2011-03-11 | 2013-12-03 | Sourcefire, Inc. | System and method for real time data awareness |
US8671182B2 (en) | 2010-06-22 | 2014-03-11 | Sourcefire, Inc. | System and method for resolving operating system or service identity conflicts |
US8677486B2 (en) | 2010-04-16 | 2014-03-18 | Sourcefire, Inc. | System and method for near-real time network attack detection, and system and method for unified detection via detection routing |
US8781969B2 (en) | 2005-05-20 | 2014-07-15 | Microsoft Corporation | Extensible media rights |
US20210319419A1 (en) * | 2004-04-26 | 2021-10-14 | Intel Corporation | Systems and methods for selling content over a network |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6963914B1 (en) * | 1998-09-01 | 2005-11-08 | Lucent Technologies Inc. | Method and apparatus for retrieving a network file using a logical reference |
US6360221B1 (en) | 1999-09-21 | 2002-03-19 | Neostar, Inc. | Method and apparatus for the production, delivery, and receipt of enhanced e-mail |
US9092535B1 (en) | 1999-09-21 | 2015-07-28 | Google Inc. | E-mail embedded textual hyperlink object |
US7840639B1 (en) * | 1999-09-21 | 2010-11-23 | G&H Nevada-Tek | Method and article of manufacture for an automatically executed application program associated with an electronic message |
WO2001052018A1 (en) | 2000-01-14 | 2001-07-19 | Microsoft Corporation | Specifying security for an element by assigning a scaled value representative of the relative security thereof |
US7737134B2 (en) * | 2002-03-13 | 2010-06-15 | The Texas A & M University System | Anticancer agents and use |
CN106603486B (en) * | 2016-11-03 | 2021-09-07 | 厦门雅迅网络股份有限公司 | Method and system for security authorization of mobile terminal |
US11157280B2 (en) * | 2017-12-07 | 2021-10-26 | International Business Machines Corporation | Dynamic fusion based on operand size |
US11256509B2 (en) | 2017-12-07 | 2022-02-22 | International Business Machines Corporation | Instruction fusion after register rename |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5005200A (en) | 1988-02-12 | 1991-04-02 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US5200999A (en) | 1991-09-27 | 1993-04-06 | International Business Machines Corporation | Public key cryptosystem key management based on control vectors |
US5164988A (en) | 1991-10-31 | 1992-11-17 | International Business Machines Corporation | Method to establish and enforce a network cryptographic security policy in a public key cryptosystem |
US5757913A (en) * | 1993-04-23 | 1998-05-26 | International Business Machines Corporation | Method and apparatus for data authentication in a data communication environment |
AU683038B2 (en) * | 1993-08-10 | 1997-10-30 | Addison M. Fischer | A method for operating computers and for processing information among computers |
US5537475A (en) | 1994-02-01 | 1996-07-16 | Micali; Silvio | Efficient digital signature algorithm and use thereof technical field |
US5799087A (en) * | 1994-04-28 | 1998-08-25 | Citibank, N.A. | Electronic-monetary system |
US5539828A (en) | 1994-05-31 | 1996-07-23 | Intel Corporation | Apparatus and method for providing secured communications |
US5694546A (en) | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
US5701343A (en) | 1994-12-01 | 1997-12-23 | Nippon Telegraph & Telephone Corporation | Method and system for digital information protection |
US5615268A (en) | 1995-01-17 | 1997-03-25 | Document Authentication Systems, Inc. | System and method for electronic transmission storage and retrieval of authenticated documents |
US5604804A (en) | 1996-04-23 | 1997-02-18 | Micali; Silvio | Method for certifying public keys in a digital signature scheme |
US5680461A (en) | 1995-10-26 | 1997-10-21 | Sun Microsystems, Inc. | Secure network protocol system and method |
US5692047A (en) | 1995-12-08 | 1997-11-25 | Sun Microsystems, Inc. | System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources |
US5602918A (en) | 1995-12-22 | 1997-02-11 | Virtual Open Network Environment Corp. | Application level security system and method |
US5956404A (en) * | 1996-09-30 | 1999-09-21 | Schneier; Bruce | Digital signature with auditing bits |
US6148349A (en) * | 1998-02-06 | 2000-11-14 | Ncr Corporation | Dynamic and consistent naming of fabric attached storage by a file system on a compute node storing information mapping API system I/O calls for data objects with a globally unique identification |
-
1998
- 1998-06-10 US US09/095,453 patent/US6684332B1/en not_active Expired - Fee Related
Cited By (67)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7529927B2 (en) | 1999-03-27 | 2009-05-05 | Microsoft Corporation | Specifying security for an element by assigning a scaled value representative of the relative security thereof |
US8005757B2 (en) | 1999-03-27 | 2011-08-23 | Microsoft Corporation | Specifiying security for an element by assigning a scaled value representative of the relative security thereof |
US20050091541A1 (en) * | 1999-03-27 | 2005-04-28 | Microsoft Corporation | Specifying security for an element by assigning a scaled value representative of the relative security thereof |
US20050091169A1 (en) * | 1999-03-27 | 2005-04-28 | Microsoft Corporation | Specifiying security for an element by assigning a scaled value representative of the relative security thereof |
US20080021839A1 (en) * | 2000-01-14 | 2008-01-24 | Microsoft Corporation | Releasing decrypted digital content to an authenticated path |
US7353209B1 (en) * | 2000-01-14 | 2008-04-01 | Microsoft Corporation | Releasing decrypted digital content to an authenticated path |
US8744969B2 (en) | 2000-01-14 | 2014-06-03 | Microsoft Corporation | Releasing decrypted digital content to an authenticated path |
US8020201B2 (en) | 2001-10-23 | 2011-09-13 | Intel Corporation | Selecting a security format conversion for wired and wireless devices |
US8601566B2 (en) * | 2001-10-23 | 2013-12-03 | Intel Corporation | Mechanism supporting wired and wireless methods for client and server side authentication |
US8522337B2 (en) | 2001-10-23 | 2013-08-27 | Intel Corporation | Selecting a security format conversion for wired and wireless devices |
US20030097592A1 (en) * | 2001-10-23 | 2003-05-22 | Koteshwerrao Adusumilli | Mechanism supporting wired and wireless methods for client and server side authentication |
US7552331B2 (en) | 2002-06-24 | 2009-06-23 | Microsoft Corporation | Secure media path methods, systems, and architectures |
US20030236978A1 (en) * | 2002-06-24 | 2003-12-25 | Evans Glenn F. | Secure media path methods, systems, and architectures |
US20060137028A1 (en) * | 2002-06-24 | 2006-06-22 | Microsoft Corporation | Secure Media Path Methods, Systems, and Architectures |
US7752674B2 (en) | 2002-06-24 | 2010-07-06 | Microsoft Corporation | Secure media path methods, systems, and architectures |
US7653943B2 (en) | 2002-06-24 | 2010-01-26 | Microsoft Corporation | Secure media path methods, systems, and architectures |
US20080063196A1 (en) * | 2002-06-24 | 2008-03-13 | Microsoft Corporation | Secure Media Path Methods, Systems, and Architectures |
US7296154B2 (en) * | 2002-06-24 | 2007-11-13 | Microsoft Corporation | Secure media path methods, systems, and architectures |
US7810163B2 (en) * | 2002-06-24 | 2010-10-05 | Microsoft Corporation | Secure media path methods, systems, and architectures |
US8700535B2 (en) | 2003-02-25 | 2014-04-15 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
US20080215896A1 (en) * | 2003-02-25 | 2008-09-04 | Steve Bourne | Issuing a Publisher Use License Off-Line in a Digital Rights Management (DRM) System |
US8719171B2 (en) | 2003-02-25 | 2014-05-06 | Microsoft Corporation | Issuing a publisher use license off-line in a digital rights management (DRM) system |
US7885190B1 (en) | 2003-05-12 | 2011-02-08 | Sourcefire, Inc. | Systems and methods for determining characteristics of a network based on flow analysis |
US8578002B1 (en) | 2003-05-12 | 2013-11-05 | Sourcefire, Inc. | Systems and methods for determining characteristics of a network and enforcing policy |
US7801980B1 (en) | 2003-05-12 | 2010-09-21 | Sourcefire, Inc. | Systems and methods for determining characteristics of a network |
US7949732B1 (en) | 2003-05-12 | 2011-05-24 | Sourcefire, Inc. | Systems and methods for determining characteristics of a network and enforcing policy |
US20050223226A1 (en) * | 2004-04-02 | 2005-10-06 | Microsoft Corporation | Authenticated exchange of public information using electronic mail |
US7721093B2 (en) | 2004-04-02 | 2010-05-18 | Microsoft Corporation | Authenticated exchange of public information using electronic mail |
US20210319419A1 (en) * | 2004-04-26 | 2021-10-14 | Intel Corporation | Systems and methods for selling content over a network |
US7996424B2 (en) | 2004-07-26 | 2011-08-09 | Sourcefire, Inc. | Methods and systems for multi-pattern searching |
US20080133523A1 (en) * | 2004-07-26 | 2008-06-05 | Sourcefire, Inc. | Methods and systems for multi-pattern searching |
US8725646B2 (en) | 2005-04-15 | 2014-05-13 | Microsoft Corporation | Output protection levels |
US20060235798A1 (en) * | 2005-04-15 | 2006-10-19 | Microsoft Corporation | Output protection levels |
US20090158036A1 (en) * | 2005-04-22 | 2009-06-18 | Microsoft Corporation | protected computing environment |
US9189605B2 (en) | 2005-04-22 | 2015-11-17 | Microsoft Technology Licensing, Llc | Protected computing environment |
US9363481B2 (en) | 2005-04-22 | 2016-06-07 | Microsoft Technology Licensing, Llc | Protected media pipeline |
US20060248594A1 (en) * | 2005-04-22 | 2006-11-02 | Microsoft Corporation | Protected media pipeline |
US8781969B2 (en) | 2005-05-20 | 2014-07-15 | Microsoft Corporation | Extensible media rights |
US20080244741A1 (en) * | 2005-11-14 | 2008-10-02 | Eric Gustafson | Intrusion event correlation with network discovery information |
US20100205675A1 (en) * | 2005-11-14 | 2010-08-12 | Sourcefire, Inc. | Systems and methods for modifying network map attributes |
US8289882B2 (en) | 2005-11-14 | 2012-10-16 | Sourcefire, Inc. | Systems and methods for modifying network map attributes |
US8046833B2 (en) | 2005-11-14 | 2011-10-25 | Sourcefire, Inc. | Intrusion event correlation with network discovery information |
US7948988B2 (en) | 2006-07-27 | 2011-05-24 | Sourcefire, Inc. | Device, system and method for analysis of fragments in a fragment train |
US20080196102A1 (en) * | 2006-10-06 | 2008-08-14 | Sourcefire, Inc. | Device, system and method for use of micro-policies in intrusion detection/prevention |
US8468351B2 (en) | 2006-12-15 | 2013-06-18 | Codesealer Aps | Digital data authentication |
US8949607B2 (en) | 2006-12-15 | 2015-02-03 | Codesealer Aps | Digital data authentication |
US20100017615A1 (en) * | 2006-12-15 | 2010-01-21 | Boesgaard Soerensen Hans Martin | Digital data authentication |
US20080209518A1 (en) * | 2007-02-28 | 2008-08-28 | Sourcefire, Inc. | Device, system and method for timestamp analysis of segments in a transmission control protocol (TCP) session |
US8069352B2 (en) * | 2007-02-28 | 2011-11-29 | Sourcefire, Inc. | Device, system and method for timestamp analysis of segments in a transmission control protocol (TCP) session |
US20080276319A1 (en) * | 2007-04-30 | 2008-11-06 | Sourcefire, Inc. | Real-time user awareness for a computer network |
US8127353B2 (en) | 2007-04-30 | 2012-02-28 | Sourcefire, Inc. | Real-time user awareness for a computer network |
US20090262659A1 (en) * | 2008-04-17 | 2009-10-22 | Sourcefire, Inc. | Speed and memory optimization of intrusion detection system (IDS) and intrusion prevention system (IPS) rule processing |
US8474043B2 (en) | 2008-04-17 | 2013-06-25 | Sourcefire, Inc. | Speed and memory optimization of intrusion detection system (IDS) and intrusion prevention system (IPS) rule processing |
US8272055B2 (en) | 2008-10-08 | 2012-09-18 | Sourcefire, Inc. | Target-based SMB and DCE/RPC processing for an intrusion detection system or intrusion prevention system |
US20100088767A1 (en) * | 2008-10-08 | 2010-04-08 | Sourcefire, Inc. | Target-based smb and dce/rpc processing for an intrusion detection system or intrusion prevention system |
US9055094B2 (en) | 2008-10-08 | 2015-06-09 | Cisco Technology, Inc. | Target-based SMB and DCE/RPC processing for an intrusion detection system or intrusion prevention system |
US9450975B2 (en) | 2008-10-08 | 2016-09-20 | Cisco Technology, Inc. | Target-based SMB and DCE/RPC processing for an intrusion detection system or intrusion prevention system |
US9282106B2 (en) * | 2009-02-20 | 2016-03-08 | Comcast Cable Communications, Llc | Authenticated communication between security devices |
US20100217985A1 (en) * | 2009-02-20 | 2010-08-26 | Comcast Cable Holdings, Llc | Authenticated Communication Between Security Devices |
US10003604B2 (en) | 2009-02-20 | 2018-06-19 | Comcast Cable Communications, Llc | Authenticated communication between security devices |
US8677486B2 (en) | 2010-04-16 | 2014-03-18 | Sourcefire, Inc. | System and method for near-real time network attack detection, and system and method for unified detection via detection routing |
US8433790B2 (en) | 2010-06-11 | 2013-04-30 | Sourcefire, Inc. | System and method for assigning network blocks to sensors |
US9110905B2 (en) | 2010-06-11 | 2015-08-18 | Cisco Technology, Inc. | System and method for assigning network blocks to sensors |
US8671182B2 (en) | 2010-06-22 | 2014-03-11 | Sourcefire, Inc. | System and method for resolving operating system or service identity conflicts |
US9135432B2 (en) | 2011-03-11 | 2015-09-15 | Cisco Technology, Inc. | System and method for real time data awareness |
US9584535B2 (en) | 2011-03-11 | 2017-02-28 | Cisco Technology, Inc. | System and method for real time data awareness |
US8601034B2 (en) | 2011-03-11 | 2013-12-03 | Sourcefire, Inc. | System and method for real time data awareness |
Also Published As
Publication number | Publication date |
---|---|
US6684332B1 (en) | 2004-01-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6684332B1 (en) | Method and system for the exchange of digitally signed objects over an insecure network | |
EP1583319B1 (en) | Authenticated exchange of public information using electronic mail | |
US7366905B2 (en) | Method and system for user generated keys and certificates | |
US6993651B2 (en) | Security protocol | |
US7036010B2 (en) | Method and apparatus for a secure communications session with a remote system via an access-controlling intermediate system | |
JP3982848B2 (en) | Security level control device and network communication system | |
US6986046B1 (en) | Method and apparatus for managing secure collaborative transactions | |
US6766453B1 (en) | Authenticated diffie-hellman key agreement protocol where the communicating parties share a secret key with a third party | |
EP1128597B1 (en) | Method and arrangement in a communication network | |
US7305548B2 (en) | Using atomic messaging to increase the security of transferring data across a network | |
US20080005562A1 (en) | Public key infrastructure certificate entrustment | |
US20030140223A1 (en) | Automatic configuration of devices for secure network communication | |
US6826685B1 (en) | Method and system for the digital certificate generation and distribution | |
GB2357229A (en) | Security protocol with messages formatted according to a self describing markup language | |
IL166660A (en) | System, method and computer program product for guaranteeing electronic transactions | |
Benantar | The Internet public key infrastructure | |
CN115801223A (en) | CA certificate-based identification key system and PKI system compatible method | |
GB2395304A (en) | A digital locking system for physical and digital items using a location based indication for unlocking | |
Nenadić et al. | Fides–a middleware e-commerce security solution | |
Gohel | Introduction to Network & Cybersecurity | |
Mueller | Let’s attest! Multi-modal certificate exchange for the web of trust | |
Wang | Security issues to tele-medicine system design | |
Parnerkar et al. | Secret key distribution protocol using public key cryptography | |
Rösler et al. | Interoperability between messaging services secure–implementation of encryption | |
JP2001189723A (en) | Communication system performing contents certification and contents certification site device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DOUGLAS, DANIEL GRAHAM;REEL/FRAME:009251/0560 Effective date: 19980608 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
REMI | Maintenance fee reminder mailed | ||
LAPS | Lapse for failure to pay maintenance fees | ||
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20160127 |