An Automatically Verified Prototype of the Tokeneer ID Station Specification

Abstract

The Tokeneer project was an initiative set forth by the National Security Agency (NSA, USA) to be used as a demonstration that developing highly secure systems can be made by applying rigorous methods in a cost-effective manner. Altran UK was selected by NSA to carry out the development of the Tokeneer ID Station. The company wrote a Z specification later implemented in the SPARK Ada programming language, which was verified using the SPARK Examiner toolset. In this paper, we show that the Z specification can be readily and naturally encoded in the $\{log\}$ set constraint language, thereby generating a functional prototype. Furthermore, we show that $\{log\}$ ’s automated proving capabilities can discharge all the proof obligations concerning state invariants as well as important security properties. As a consequence, the prototype can be regarded as correct with respect to the verified properties. This provides empirical evidence that Z users can use $\{log\}$ to generate correct prototypes from their Z specifications. In turn, these prototypes enable or simplify some verification activities discussed in the paper.

Appendices

A. Further Details on the Encoding

In this appendix, we provide more details and examples of the necoding used to go from the TIS Z specification to the $\{log\}$ prototype.

Figure 2 shows part of the Z specification and Fig. 3 the corresponding encoding. Schema BioCheckRequired specifies part of the ValidateUserTokenOK operation which in turn is part of the TISValidateUserToken operation. BioCheckRequired makes a ‘delta’ on IDStation and RealWorld; this is hidden in schema UserEntryContext. This is reflected in the encoding as clause bioCheckRequiredwaits for IDStationand IDStation_, meaning that the clause transitions from the former to the latter. As explained in Sect. 2, IDStation includes 12 schemas and declares two variables. Then, the encoding for IDStation is a 14-tuple respecting the declaration order given in the specification. As mentioned in Sect. 2.1, the invariants stated inside IDStation are moved out of it. Note that $IDStation'$ is encoded as IDStation_.

As BioCheckRequired states $\Xi UserToken$ the encoding forces UserTokenand UserToken_to be the first elements of IDStationand IDStation_, respectively, while UserToken_ = UserToken is conjoined to the clause.

AddElementsToLog is an operation schema making a ‘delta‘ on the auditing subsystem, AudiLog, and accessing the configuration subsystem, Config. In $\{log\}$ this schema corresponds to clause addElementsToLog. The clause is called inside a delay predicate for efficiency reasons. After the first proof obligations were discharged it was evident that addElementsToLogwas taking too long while not contributing to the proofs. Hence, we ask $\{log\}$ to delay its execution as much as possible. AddElementsToLog’s predicate starts by asserting the existence of a finite set of audit records, newElements. The $\{log\}$ encoding reflects that fact by declaring variable _NewElementsinside the clause and passing it to addElementsToLog. This simplifies the encoding of some tricky parts of the specification.

In BioCheckRequired, status is a variable declared in schema Internal (which is one of the 12 schemas included in IDStation). The encoding uses unification to access the corresponding variable, Status. Indeed, unification forces Internalto be the 12th component of IDStationand it is used again to force Statusto be the first component of Internal. Then, we can state Status = gotUserToken. Note how the change of state of status is encoded by asserting Status_ = waitingFinger.

Fig. 2

Comparison between Z code and $\{log\}$ code. Z specification

Fig. 3

Comparison between Z code and $\{log\}$ code. $\{log\}$ code corresponding to Fig. 2

The predicate $\lnot UserTokenWithOKAuthCert$ is encoded by calling the negation of userTo-kenWithOKAuthCert. As explained in Sect. 3 (see Example 7), in order to preserve decidability (general) logical negation should not be used. Figure 4 shows the encoding of $\lnot UserTokenOK$ (in place of $\lnot UserTokenWithOKAuthCert$, which is nonetheless similar). There are several reasons why the user token is not OK. The first one occurs when the current user token does not belong to the range of goodT. This implies that it must be either noT or badT (see TOKENTRY above). The encoding is CurrentUserToken in noT, badT. The other cases occur when there is a token : Token such that $currentUserToken = goodT(token)$. In this case, (token, now) might not conform to a current token (not_currentToken(Token,Now)); or now might not coincide with currentTime (Now neq CurrentTime); or any of the certificates stored in token are not OK (not_certOK(KeyStore,[_,_,_])).

To close this section, note that the $\{log\}$ encoding of ValidateUserTokenOK turns out to be quite ’natural’ (both, syntactically and semantically). This encoding becomes sort of a pattern by means of which most of the Z specification is encoded. Considering the size and complexity of the TIS Z specification, it can be argued that $\{log\}$ can be used as an effective prototyping/programming language to encode many other Z specifications.

Fig. 4

Encoding of $\lnot UserTokenOK$

B. Further Details on the Proof of Property 1

Figures 5 and 6 depict the state sequences that lead the system to the state where Property 1 holds. Figure 7 shows the encoding of a lemma stating that if the system ever reaches $status = gotUserToken$, it is because the before state was $status = quiescent$—i.e., the first transition of Fig. 5. That is, the $\{log\}$ code corresponds to the negation of the following formula:

$$\begin{aligned}&\varDelta IDStation; \varDelta RealWorld | \\&TISOpThenUpdate \\&\wedge enclaveStatus \ne waitingStartAdminOp \\&\wedge status' = gotUserToken \wedge status' \ne status \\&\vdash \\&status = quiescent \end{aligned}$$

where TISOpThenUpdate is the composition between the disjunction of all the TIS operations and the TISUpdate operation [10, page 5].

Fig. 5

Sequences of state changes leading to $status = waitingRemoveTokenSuccess$

Fig. 6

Sequence of state transitions leading to $enclaveStatus = (waitingStartAdminOp, rolePresent \ne \emptyset )$

Fig. 7

Encoding of a state change lemma

We prove one such lemma for each transition shown in Figs. 5 and 6. In this way, the $\{log\}$ prototype is guaranteed to follow only those state sequences when it comes to the validity of Property 1.

Next, we prove that when the system reaches some of the states depicted in Figs. 5 and 6 some properties hold. For example, when passing from gotUserToken to waitingEntry, the user token is checked for validity and the presence in the token of an authorization certificate is checked as well. Figure 8 shows the encoding of this lemma. As can be seen, we need pfun(IssuerKey_)as a hypothesis. In Z terms, this means that $issuerKey'$ is a partial function, which is the type given to the variable in the specification. This hypothesis is proved to be a state invariant and so it can be assumed without loss of generality.

Fig. 8

Encoding of a lemma stating an intermediate property

C. Platform Where the Verification was Executed

The verification of the $\{log\}$ prototype of the TIS specification was performed on a Latitude E7470 (06DC) with a 4 core Intel(R) Core™ i7-6600U CPU at 2.60GHz with 8 Gb of main memory, running Linux Ubuntu 18.04.4 (LTS) 64-bit with kernel 4.15.0-106-generic. $\{log\}$ 4.9.6-21c over SWI-Prolog (multi-threaded, 64 bits, version 7.6.4) was used during the experiments. The execution time of each collection of proof obligations is given by Tin the following $\{log\}$ formula:

prolog_call(get_time(Ti))&

<collection proof obligations>

prolog_call(get_time(Te)) &

prolog_call(T is Te - Ti).

where prolog_callis a $\{log\}$ facility to access the Prolog interpreter.