Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability

Definitions

• the invention relates to security trusts. More particularly, the invention relates to allowing code signed by a master key to grant trust to an arbitrary second key, and allowing code, referred to as an antidote, also signed by the master key to revoke permanently the trust given to the secondary key.
• the definition of trust has two parts.
• the first part is establishing identity of a participant.
• the participant has, as an analogy a letter of introduction signed by some other entity.
• the signing entity is typically referred to as a certificate of authority, or CA.
• CA certificate of authority
• the certificate of authority, or simply, certificate establishes the participant's name and signature.
• Other terms used interchangeably with certificate are master key, super key, and system certificate. Therefore, the participant's identity is a letter of introduction signed by a CA.
• the second part is a statement of trust, which according to the analogy above may be a letter stating trust the participant. That is, the first step is to establish identity of a participant, and the second step is an agreement provided stating trust such identity. The identity and the agreement together work to establish trust.
• CRL's From a typical computer system's perspective, an example of an implementation of trust is accomplished by using CRL's.
• CRL's The use of CRL's is bundled with the released software.
• Associated with the released software is a system certificate.
• This certificate along with a plurality of other certificates reside in a certificate database.
• the use of certificates is adaptable to be applied to releases of additional software released by the same entity that released the first system code. Sometimes they are referred to as patches. Signed patches mean for the end user to trust the patches as well as the originally signed software.
• Tallman, U.S. Patent No. 5,619,657 (Apr. 8, 1997) discloses a method for providing a security facility for a network of management servers utilizing a database of trust relations to verify mutual trust relations between management servers.
• the disclosure consists of a method for providing security for distributing management operations among components of a computer network using a network of mutually trusting, mutually authenticating management services to dispatch operations to selected host systems.
• Mutual authentication and trust are established on every transmission link from a point of submission to a designated management server which invokes a service provider to perform management operations on a selected host.
• the user is required to certify that the workstation in question possessing the private encryption key is authorized to speak on the user's behalf.
• partner code it would be advantageous to provide an elegant, simple, and efficient means to revoke the trust previously granted to partner code. It would be advantageous to allow partner code to be signed by its own, unique certificate so as not to impact the release of other code signed by other certificates.
• a method and apparatus is provided that essentially adds two elements of functionality to a client.
• the first element of functionality allows code signed by a master key to grant power, or trust to an arbitrary second, or minor key.
• the second element of functionality allows code, referred to as an antidote, signed by a master key to preclude giving power to a specific secondary key permanently.
• the master key is used to sign only extremely small elements of code. These code elements convey either a grant or denial of trust for a secondary key. The fact that these sections of code are small and simple ensures no errors are made in the code and hence the master key never needs to be revoked.
• the idea of the antidote is that trust can be permanently denied for a secondary key. Once the antidote is applied by rerunning the trust code, the secondary key will never have any more effect. From a usage perspective, the code fragment is run as an upgrade to combat a security breach that was discovered. The upgrade running the antidote permanently prevents the upgraded client from paying attention to the trusted code that has been breached. This makes the granted trust benign once it is breached.
• Fig. 1 shows a schematic diagram of a trust system according to the prior art
• Fig. 2 shows a schematic diagram of a trust system according to the invention.
• a method and apparatus that essentially adds two elements of functionality to a client.
• the first element of functionality allows code signed by a master key to grant power, or trust to an arbitrary second, or minor key.
• the second element of functionality allows code, referred to as an antidote, signed by a master key to preclude giving power to a specific secondary key permanently.
• the master key is used to sign only extremely small elements of code. These code elements convey either a grant or denial of trust for a secondary key. The fact that these sections of code are small and simple ensures no errors are made in the code and hence the master key needs never to be revoked.
• the idea of the antidote is that trust can permanently be denied for a secondary key. Once the antidote is applied by rerunning the trust code, the secondary key will never have any effect. From a usage perspective, the code fragment is run as an upgrade to combat a security breach that was discovered. The upgrade running the antidote permanently prevents the upgraded client from paying attention to the trusted code that has been breached. This makes the granted trust benign once it is breached.
• the invention can be understood by an example problem and its solution.
• the example is of a client shipping software to end users and the client's partner desiring to ship software that can be viewed as an add on to the client's software.
• the problem can arise when both the client software and the partner software are each signed by a single master key.
• a master key 100 signs system code 101 of a client. At some point later in time, the client releases an additional patch of code 102 that is also signed by the master key 100 to ensure that all code works in unison. When it is desired to ship or release partner code 103 of the client that is associated with or added on to the client code the master key 100 also signs the partner code 103. Such signing 104 by the master key 100 can be viewed as dangerous because the partner code 103 might have errors. This can be particularly troublesome when the partner code 103 is a large body of code.
• the corrective procedure according to the prior art is to correct the errors in the partner code 103 and subsequently redistribute the entire amount of previously distributed code (101 -103) containing the corrections and again signed by the master key 100.
• a solution to the problem is as follows.
• the partner creates a secondary or minor key 200.
• the client provides empowerment or trust code 201 signed by the master key 100 that essentially allows trusting the minor key
• antidote code 203 is created, signed by the master key 100, and distributed when necessary to users of the trusted partner code 202.
• a small piece of Application Programming Interface (API) add/destroy trust code 204 is provided for the client's system 205.
• This API 204 is also signed by the master key 100.
• the empowerment code 201 and the antidote code 203 each make calls to this API to ensure that the system 205 has the ability to add or destroy the trust granted by the minor key 200.
• implementation is as follows. First the add/destroy trust API 204 is added to the system 205. Then the client simply writes the small piece of empowerment code 201 and the small piece of antidote code 203 that each make calls to the API 204. In the preferred embodiment, any of the API, empowerment, and antidote code is written in, but not limited to the Java or JavaScript programming languages, or in any other general purpose code.
• the granting and revoking of trust according to the invention is performed outside of the standard infrastructure as in using certificates and revocation lists as according to the prior art.
• the master key or certificate is trusting code, as opposed to trusting another certificate or key as according to the prior art.
• the invention does not require the standard general mechanism of certificate revocations lists, whereby validating a particular certificate requires accessing a central area to check for revocations.
• an upgrade is downloaded to the end user, wherein the upgrade carries the revocation of the trust.
• the antidote code 203 destroying trust is more powerful than the empowerment code 201 together with the signed partner code 203 making the added trust. That is, the antidote code 203 has permanence meaning that when the system 205 encounters trusted partner code 202 signed by the minor key 200 at a later point in time and after the antidote code 203 has been applied, the system 205 will continue to honor the revocation of trust by the minor key 200.
• a new minor key is issued and the adding of trust can be reinstated.
• each partner can have its own unique minor key.
• an end user is presented with dialog boxes asking the end user whether or not the end user trusts code about to be loaded or run.
• dialogs typically confuse the end user.
• dialog boxes are avoided.
• the end user When an end user requests the upgrade containing the partner code add on, the end user actually receives the signed (by the master key) empowerment code and the signed (by the minor key) partner code, without receiving any questions.
• the end user experiences the system code, any additional patches, and powerful partner code all working together seamlessly.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Storage Device Security (AREA)
• Lock And Its Accessories (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=21742601

Family Applications (1)

Country Status (6)

Families Citing this family (4)

Citations (1)

Family Cites Families (3)

• 2001
  • 2001-05-25 CN CNB018232930A patent/CN1326006C/zh not_active Expired - Fee Related
  • 2001-05-25 JP JP2003509288A patent/JP2004535118A/ja active Pending
  • 2001-05-25 CA CA002447649A patent/CA2447649C/en not_active Expired - Fee Related
  • 2001-05-25 WO PCT/US2001/017128 patent/WO2003003176A1/en active IP Right Grant
  • 2001-05-25 AU AU2001263462A patent/AU2001263462B2/en not_active Ceased
  • 2001-05-25 EP EP01937758A patent/EP1390828A1/de not_active Ceased

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events