Research And Implementation Of A Non-repudiation Service For CORBA

The Common Object Request Broker Architecture (CORBA), is theObject ManagementGroup's answer to the need for interoperability amongthe rapidly proliferating number of hardware and software productsavailable today. Simply stated, CORBA allows applications tocommunicate with one another no matter where they are located or whohas designed them. CORBA 1.1 was introduced in 1991 by ObjectManagement Group (OMG) and defined the Interface Definition Language(IDL) and the Application Programming Interfaces (API) that enableclient/server object interaction within a specific implementation ofan Object Request Broker (ORB). CORBA 2.0, adopted in December of 1994,defines true interoperability by specifying how ORBs from differentvendors can interoperate. CORBA3.0 is the current release.This paper focuses on the provision of a non-repudiation servicefor CORBA. The Non-repudiation Service provides evidence ofapplication actions in a form that cannot be repudiated later. Thisevidence is associated with some data (for example, the amount fieldof a funds transfer document). Non-repudiation tokens may be freelydistributed. Any possessor of a non-repudiation token (and theassociated data, if not included in the token) can use thenon-repudiation Service to verify the evidence. Any holder of anon-repudiation token may store it (along with the associated data,if not included in the token) for later adjudication.The non-repudiation interfaces support generation and verificationof tokens embodying several different types of evidence. It isanticipated that the following will be the most commonly usednon-repudiation evidence token types:Non-repudiation of Creation prevents a message creator's false denial of creating a message.Non-repudiation of Receipt prevents a message recipient's false denial of having received a message.The current OMG specification of a CORBA non-repudiation serviceforces the programmer to augment the applicaton with calls to functions...