Dynamic classes of service for an international cryptography framework

• US 5,841,870 A
• Filed: 11/12/1996
• Issued: 11/24/1998
• Est. Priority Date: 11/12/1996
• Status: Expired due to Fees

• Current Assignee: Cheyenne Property Trust
• Original Assignee: Cheyenne Property Trust
• Inventors: Merckling, Roger, Klemba, Keith, Fieres, Helmut
• Primary Examiner(s): Cain, David
• Application Number:
  US08/748,085
• Time in Patent Office: 742 Days
• Field of Search: 380/23, 380/25, 380/52, 380/4, 380/49
• US Class Current: 713/156
• CPC Class Codes: G06F 21/51 at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
• CPC Class Codes: G06F 21/57 Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Abstract

An international cryptography framework (ICF) allows manufacturers to comply with varying national laws governing the distribution of cryptographic capabilities. The invention is concerned primarily with the application certification aspects of the framework where an application that requests cryptographic services from the ICF service elements is identified through some form of certificate to protect against the misuse of a granted level of cryptography. The levels of cryptography granted are described via security policies and expressed as classes of service. A cryptographic unit, one of the ICF core elements, can be used to build several certification schemes for application objects. The invention provides various methods that determine the strength of binding between an application code image and the issued certificates within the context of the ICF elements. A key element with regard to the exercise of a cryptographic function concerns the special requirements for the trust relation that an authority specifies for the cryptographic unit. Any function exercised by the cryptographic unit must be controllable by the associated class of service which represents the security policy. Touchpointing, both in the application and the firmware elements inside the cryptographic unit, plays a key role in exercising control over the functioning of these modules. Another fundamental requirement of the ICF architecture is that the application is assured of the integrity of the cryptographic unit from which it is receiving services. Thus, the invention also provides methods that allow a determination of whether or not the cryptographic unit has been replaced or tampered with.

Claims

1. A method for validating that an application rightfully executes a certain class of service, comprising the steps of:

either defining classes of service with an application domain authority or creating classes of service with a security domain authority;

wherein said classes of service are validated by said security domain authority which has policies defined to meet said security domain authorities'"'"' security interests and requirements, where said class of service has a unique identification that is not reused by said security domain authority;

granting said level of authority from said application domain authority in the form of a certificate containing valid classes of services; and

tightly binding said application to said certificate.

2. The method of claim 1, further comprising the step of:

establishing trust between said application and a cryptographic unit, wherein said application is assured that said cryptographic unit has not been tampered with.

3. The method of claim 1, further comprising the steps of:

performing application validation with a trusted load subsystem;

loading a program image into a system memory space; and

while doing that,

validating that said application has not been tampered with.

4. The method of claim 3, wherein said application validation step further comprises the step of:

using a checksum over a program image;

wherein the load fails and said program image is not loaded if the checksum does not match a checksum stored by a loader subsystem at application installation time.

5. The method of claim 1, further comprising the step of:

validating any object governed by a certificate.

6. The method of claim 2, further comprising the step of:

challenging said cryptographic unit.

7. The method of claim 2, further comprising the steps of:

shipping said application to a target system in a scrambled form; and

preparing said application to function with said cryptographic unit;

wherein only a cryptographic unit which has a correct decryption key can unscramble said application.

8. The method of claim 1, where said class of service has a unique identification that is not reused by said security domain authority.

9. The method of claim 1, further comprising the step of:

providing a class of service from said security domain authority to said application domain authority to allow said application domain authority to issue application certificates for an application which contains said class of service;

wherein a path of access control is formed.

10. The method of claim 1, wherein an application must have a certificate to access a method identified by said class of service.

11. The method of claim 2, further comprising the step of:

propagating a class of service to said cryptographic unit to enable said class of service at a target cryptographic unit;

wherein methods labelled by said class of service must be in a present state for a request to be executed.

12. The method of claim 1, wherein both control of access and control of existence of a method must always be present to maintain a method defined by said application in a functioning state.

13. The method of claim 2, further comprising the step of:

activating said cryptographic unit with a policy before an application can be granted a class of service via said application certificate.

14. The method of claim 13, wherein said cryptographic unit must be in communication with a policy for said class of service to be downloaded.

15. The method of claim 14, wherein said policy is a virtual policy that requires a network connection to a network security server to distribute said virtual policy to said cryptographic unit.

16. The method of claim 14, wherein said policy is a physical policy that requires said cryptographic unit to implement touchpoints in hardware;

wherein said touchpoints are placed in deterministic locations in said hardware; and

wherein a policy containing touchpoint data can be loaded, but cannot be removed from said cryptographic unit without a decay of said application'"'"'s function.

17. The method of claim 16, wherein said class of service contains the touchpoint data necessary to control said touchpoints inside said cryptographic unit.

18. The method of claim 1, wherein said class of service contains a method field that describes an actual method for which said class of service stands.

19. The method of claim 1, wherein said class of service contains a constraints field that describes attributes of said method.

20. The method of claim 1, wherein the interval for which a class of service can be declared to be valid may be unbounded or may be considered by a predetermined criteria.

21. The method of claim 1, wherein classes of service are organized not only by an object that they describe, but also by a level of validation or set of constraints an implementation performs before granting a service level described by said class of service.

22. The method of claim 20, said class of service further comprising:

a special, predefined class of service that is used to guard class of service decay functionality.

23. The method of claim 22, wherein tighter validation and control over a service to be granted is achieved based upon said level of validation or set of constraints.

24. The method of claim 23, further comprising the step of:

providing a class of service level that validates a class of service ID, as it is made available through an application certificate, has been signed by a security domain authority.

25. The method of claim 24, further comprising the step of:

providing a class of service level that requires validation of said application certificate, where said certificate is required to be issued by said application domain authority that requested the class of service identified by said class of service ID from said security domain authority.

26. The method of claim 25, further comprising the step of:

providing a class of service level that requires validation of said application ID issued by said application domain authority.

27. The method of claim 26, further comprising the step of:

providing a class of service level that requires interaction with a network security server to validate said class of service requested by said application.

28. The method of claim 27, further comprising the step of:

providing a class of service level that interacts with said network security server on each operation requested by said application.

29. The method of claim 28, further comprising the step of:

providing a class of service level that requires a token for anyone, or combination of, validations and interactions.

30. The method of claim 29, wherein said class of service levels may be provided alone or in combination.

31. An apparatus for validating that an application rightfully executes a certain class of service, comprising:

an application domain authority for granting a level of authority in the form of a certificate containing valid classes of service;

means for either creating classes of service with a security domain authority or for defining classes of service with said application domain authority, where said classes of service are validated by said security domain authority which has policies defined to meet said security domain authorities'"'"' security interests and requirements, where said class of service has a unique identification that is not reused by said security domain authority; and

means for tightly binding said application to said certificate.

32. The apparatus of claim 31, further comprising:

a cryptographic unit; and

means for establishing trust between said application and said cryptographic unit, wherein said application is assured that said cryptographic unit has not been tampered with.

33. The apparatus of claim 31, further comprising:

a trusted load subsystem for performing application validation;

means for loading a program image into a system memory space; and

while doing that, validating that said application has not been tampered with.

34. The apparatus of claim 33, wherein said trusted load subsystem further comprises:

means for using a checksum over a program image;

wherein the load fails and said program image is not loaded if the checksum does not match a checksum stored by a loader subsystem at application installation time.

35. The apparatus of claim 31, further comprising:

means for validating any object governed by a certificate.

36. The apparatus of claim 31, further comprising:

means for challenging said cryptographic unit.

37. The apparatus of claim 32, wherein said application is shipped to a target system in a scrambled form;

said apparatus further comprising;

means for preparing said application to function with said cryptographic unit;

wherein only a cryptographic unit which has a correct decryption key can unscramble said application.

38. The apparatus of claim 31, where said class of service has a unique identification that is not reused by said security domain authority.

39. The apparatus of claim 31, further comprising:

means for providing a class of service from said security domain authority to said application domain authority to allow said application domain authority to issue application certificates for an application which contains said class of service;

wherein a path of access control is formed.

40. The apparatus of claim 31, wherein an application must have a certificate to access a method identified by said class of service.

41. The apparatus of claim 32, further comprising:

means for propagating a class of service to said cryptographic unit to enable said class of service at a target cryptographic unit;

wherein methods labelled by said class of service must be in a present state for a request to be executed.

42. The apparatus of claim 31, wherein both control of access and control of existence of a method must always be present to maintain a method defined by said application in a functioning state.

43. The apparatus of claim 32, further comprising:

a policy for activating said cryptographic unit before an application can be granted a class of service via said application certificate.

44. The apparatus of claim 43, wherein said cryptographic unit must be in communication with a policy for said class of service to be downloaded.

45. The apparatus of claim 39, wherein said policy is a virtual policy that requires a network connection to a network security server to distribute said virtual policy to said cryptographic unit.

46. The apparatus of claim 39, wherein said policy is a physical policy that requires said cryptographic unit to implement touchpoints in hardware;

wherein said touchpoints are placed in deterministic locations in said hardware; and

wherein a policy containing touchpoint data can be loaded, but cannot be removed from said cryptographic unit without a decay of said application'"'"'s function.

47. The apparatus of claim 46, wherein said class of service contains the touchpoint data necessary to control said touchpoints inside said cryptographic unit.

48. The apparatus of claim 31, wherein said class of service contains a method field that describes an actual method for which said class of service stands.

49. The apparatus of claim 31, wherein said class of service contains a constraints field that describes attributes of said method.

50. The apparatus of claim 31, wherein the interval for which a class of service can be declared to be valid may be an unbounded or may be constrained by predetermined criteria.

51. The apparatus of claim 50, said class of service furtier comprising:

a special, predefined class of service that is used to guard class of service decay functionality.

52. The apparatus of claim 31, wherein classes of service are organized not only by an object that they describe, but also by a level of validation or set of constraints an implementation performs before granting a service level described by said class of service.

53. The apparatus of claim 52, wherein tighter validation and control over a service to be granted is achieved based upon said level of validation or set of constraints.

54. The apparatus of claim 52, further comprising:

a class of service level that validates a class of service ID, as it is made available through an application certificate, has been signed by a security domain authority.

55. The apparatus of claim 54, further comprising:

a class of service level that requires validation of said application certificate, where said certificate is required to be issued by said application domain authority that requested the class of service identified by said class of service ID from said security domain authority.

56. The apparatus of claim 55, further comprising:

a class of service level that requires validation of said application ID issued by said application domain authority.

57. The apparatus of claim 56, further comprising:

a class of service level that requires interaction with a national security server to validate said class of service requested by said application.

58. The apparatus of claim 57, further comprising:

a class of service level that interacts with said national security server on each operation requested by said application.

59. The apparatus of claim 58, further comprising:

a class of service level that requires a token for any one, or combination of, validations and interactions.

60. The apparatus of claim 59, wherein said class of service levels may be provided alone or in combination.