T 2558/12 (Trust in a cryptographic token/HEWLETT-PACKARD) 17-12-2015

The invention

1. In general terms, the application is concerned with estab­li­shing whether a user is authorised to perform a spe­cific "trusted transaction or trusted commu­nication" and, if so, allowing the transaction or communication (henceforth referred to as "action").

1.1 It is disclosed that a user, requesting a computer appli­­cation to perform some action, will present a di­gi­tal cer­tificate (e.g. based on the X.509 standard) which contains, inter alia, the user's public key signed by a certificate authority (paragraphs 1 and 23). The user will also present what is called a "cryp­tographic ser­vice module" CSM and/or a "cryp­to­graphic token" which "performs the cryptography" (paragraph 2). The requested computer application will determine its trust in the cryp­tographic token, for instance using a challenge-res­ponse dialogue (hence the computer appli­ca­tion is also referred to as the "challenger appli­ca­tion").

1.2 The term "cryptographic token" is used to refer broadly to a variety of security mechanisms available "to safe­guard access to a private key" (see paragraph 25), based on hardware, software or firmware. These crypto­gra­phic tokens are characterised by their "physical pa­rameters", such as token type, or "operative parame­ters", such as supported cryptographic operations or key length (see paragraph 26).

1.3 It is disclosed that these parameters may have a bea­ring on "the ability of the cryptographic token to pro­tect private keys or other secrets", and hence their "se­­cu­ri­ty" or the "trust" that can be put into them (pa­ragraphs 25 and 26). The appli­cation is concerned with the prob­lem of how to "estab­lish trust" towards a user and its cryp­tographic token.

2. As a solution, the application proposes to store secu­ri­ty-relevant parameters of the cryptographic token in the digital certificate (preferably in ex­tension fields pro­vided by version 3 of the X.509 stan­dard; see para­graphs 10 and 12), cryptographically signed, and to communicate them with the certi­fi­cate to the challenger applica­tion, so that it­­ can determine its trust in the cryp­to­gra­phic token (see e.g. paragraph 29). In doing this, "different challenger applications [may be] free to in­terpret the physical and/or operative parameters in­de­pendent­ly" (paragraph 33). Depending on the de­ter­mined le­vel of trust, the challenger application may allow the user to perform the requested action, fully or in limi­ted form, or disallow it (see e.g. paragraphs 46 and 55).

Terminological issues and claim construction

3. Claim 1 of all requests is directed to a "method for determining by a challenger a level of trust to put in a digital certificate", which is stored "in a way to be accessible via a cryptographic service module (110) coupled to a cryptographic token". Claim 1 further spe­ci­fies that the digital certificate comprises "physical and ope­ra­tive parameters of the cryptographic token".

3.1 The board notes that this wording refers to a crypto­gra­phic service module and a cryptographic token, but that neither is actually part (i.e. feature or object) of the claimed method. In this regard, the board dis­agrees with the appellant's state­ment made in its reply dated 17 No­vember 2015 (see page 2, last paragraph).

3.2 The board also observes that a digital certificate may be accessible "via" more than one cryptographic service mo­dule or cryptographic token so that it is unclear which is "the" specific cryptographic token the para­meters of which are recited in the claim.

3.3 Furthermore, claim 1 does not require that the recited pa­ra­me­ters are obtained or derived from the crypto­gra­phic token, nor that they are or could be validated against it. ­­As a consequence, the parameters may or may not be an accurate characterisation of the token in ques­­tion, and, hence, any conclusion drawn from these parameters may or may not be reliable.

3.4 Moreover, the term "level of trust" is a vague one. The method specifies the "level of trust" as a value used to control access to an action but does not otherwise give meaning to the concept of "trust". The board takes it that "trust" is a matter of con­ven­tion, based on uni­la­te­ral "interpretation" by the challenger applica­tion (see also paragraph 33 of the de­scription) or based on "agreement" between the relevant parties. Ei­ther way, the notion of "trust" does not have any spe­ci­fic tech­ni­cal meaning.

4. The foregoing notwithstanding, the board considers that the claimed subject-matter is clear enough to be assessed for inventive step, Article 56 EPC 1973.

The prior art

5. D1 relates to computer security based on a PKI archi­tec­­ture and discloses digital certificates com­pri­sing a user's identity and the user's public key, "bound" to­gether by a digital signature of the certifi­ca­tion au­tho­­rity CA (page 1, line 31, to page 2, line 13). The cer­­­­ti­­fi­cate is evaluated to determine "whe­ther or not to trust a user's signature" (loc. cit.) and thus whe­ther a requested transaction is allowed or not (page 2, lines 14-18). D1 fur­ther discloses that an X.509 cer­ti­fi­cate (version 2, see page 3, line 8) may be ex­ten­ded by "po­li­cy elements" or "policy identifiers" (page 3, lines 7-31), which define for instance key sizes, whe­ther a customer must appear per­sonally before an au­tho­rity or how customers have to identify themselves. It is dis­closed that there are "mandatory requirements" such as (certificate) validity, whereas the cer­ti­ficate poli­cy extension contains "discretionary require­ments" (page 11, line 17; page 13, lines 26-32). The latter can be en­­forced at need by the Programmable Policy Mo­dule (PPM) (loc. cit.; page 5, last paragraph; page 11, lines 17-32; page 18, lines 6-8; claim 13).

Inventive step

6. In the board's view, the PPM of D1 qualifies as a "challen­ger" according to the claimed invention which allows/disallows a trusted action based on "parameters" contained in a digital certificate. The board also con­si­­ders that the PPM only allows an action if it has es­tab­lished a sufficient "level of trust" in the given cer­ti­ficate (see page 1, line 32, to page 2, line 2). In the board's judg­ment, at least some of the po­licy ele­ments disclosed in D1 qualify as "ope­rative pa­rame­ters of the cryptographic token" (in particular the "key size", "key algorithm" and "key usage algo­rithm"; see D1, page 3, lines 7-21, and page 11, line 31; and com­pare the application, paragraph 26).

7. Claim 1 of the main request thus differs from D1 in the following features:

a) D1 does not disclose that the challenger allows or disallows an action according to whether the de­ter­mined "level of trust" is greater or less than a given threshold.

b) D1 arguably does not disclose that the digital certificate contains "physical parameters [...] of the cryptographic token", certainly not as defined in the description in paragraph 25.

c) D1 does not disclose that the "token information" contained in the licence is cryptographically signed.

Claim 1 of the auxiliary requests further differs from D1 in the claimed alternatives from which the "physical and operative parameters" of the cryptographic token are to be selected.

7.1 The appellant argues that the invention solves the prob­lem of "provid[ing] an improved approach for de­ter­mining the level of trust in a digital certi­fi­cate" (see grounds of appeal, page 5, paragraph 3).

7.2 The board considers that this formulation is unsuitable for defining the objective techni­cal problem solved by the invention, firstly because, as argued above, the con­cept of "trust" has no clear, if any, technical meaning, se­cond­ly because the level of trust is not "determined" in a technical sense, and, thirdly and foremost, be­cause it is not clear in what manner the invention "im­proves" the way of "determining the level of trust".

7.3 The board rather takes the view that the three diffe­rences address three separate and independent problems. Feature a) concerns the question of how the policy en­force­ment known from D1 is implemented, feature b) the question of which parameters may affect "trust", and fea­ture c) the question of ensuring the integrity of the policy-relevant information itself.

8. Regarding difference c), the board considers that digi­tal signatures are an obvious solution to the given problem. It is known from D1 to sign the user's iden­tity with the user's public key so as to enable veri­fi­cation that a public key belongs to the asserted user. The board deems natural the desire to validate the to­ken information in the same way, so as to make sure that the policy enforcement cannot be bypassed by for­ging the token information. To this end, the skilled person would find it obvious to provide a digital sig­nature of the token information, too.

9. Regarding difference a), the board considers that the use of thresholding is an obvious way of arriving at a binary decision. For example, if keys were trusted the more the longer they are, the "trust level" associated with a key would be effectively the key length. If, then, a policy requirement was a minimum key length (see D1, page 3, lines 14-15) it would be obvious for the skilled person to evaluate whether the key length exceeded the minimum length threshold and allow or dis­allow the requested action accordingly.

10. By way of difference b), the invention proposes a po­licy - or, rather, a set of po­licy criteria - different from those disclosed in D1.

10.1 The board agrees with the examining division that the choice of policy may be a matter of agreement between "the two parties" (see decision, reasons 4.4), although it may also be a unilateral decision of the challenger (as disclosed in the application, paragraph 33). The board also agrees with the decision that the choice of policy, in itself, does not contribute to the technical character of the invention.

10.2 If one were to introduce the policy that a cer­tain ac­tion should only be carried out with a par­ti­cu­lar kind of tamper-resistant token, then this choice it­self would not solve a technical prob­lem. In parti­cular, the security advantage of tamper re­sistance is achieved by the token rather than the policy deci­sion to require it. Coming up with a new policy thus does not solve a tech­ni­cal problem but ex­presses the wish to exploit a known advantage.

10.3 It is noted in passing that a policy need not imply any specific technical advantage. For instance, if one were to decide that only cryptographic tokens of a parti­cu­lar manufacturer were to be trusted (as listed in claim 1 of the auxiliary requests), then this might in itself express some form of "trust" in that manufacturer but leaves open what technical properties it might have to guarantee so as to earn and maintain that trust.

10.4 For the foregoing reasons, established jurisprudence of the boards of appeal (in particular T 641/00 COMVIK; head­note 2) pro­vides that the details of the chosen po­li­­cy may le­gi­ti­ma­tely appear in the formulation of the problem to be solved rather than the solution. For claim 1 this would be the problem of modifying D1 so as to take into account "phy­sical parameters of the cryp­to­graphic token" (main re­quest) or "physical and ope­ra­tive parameters [...] se­lected from the group" as defined in claim 1 (auxiliary requests).

10.5 Given that D1 already discloses the defi­nition of po­li­cies in certificates and their enforcement by the challenger, it would be obvious for the skilled person to modify D1 so as to take into account other or addi­tional policy parameters.

10.6 Therefore, the board comes to the conclusion that claim 1 of all three pending requests lacks an inventive step over D1, Article 56 EPC 1973.