Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

Session and Authorization: Compared and Contrasted

Sessions and authorizations are closely related and sometimes overlapping concepts in the TPM 2.0 specification, but they are not synonymous terms. Sessions are the vehicle for authorizations, but they're also used for purposes other than authorization, in conjunction with authorizations or completely independent of them. For example, sessions used for authorization can also be used to specify per-command modifiers such as encrypt, decrypt, and audit. Sessions can also be used for these per-command modifiers without being simultaneously used for any authorizations at all.

The TPM 2.0 specification itself often overlaps the terms session and authorization.

Here are some examples of this in the specification:

• The authorization area[1] in commands is used for both authorizations and sessions. But sessions can be used in ways that have nothing to do with authorization. For instance, they can be used to set up encryption and decryption of command and response parameters and to enable auditing of commands. Sessions that have nothing to do with authorization can be configured for these purposes.

• The TPM_ST_NO_SESSIONS and TPM_ST_SESSIONS tags are used to indicate whether an authorization area is present in a command, an obvious lack of consistency in nomenclature.

• Sessions are started with the TPM2_StartAuthSession command.

The name of the command indicates that an authorization is being started, but in fact a session is being started by this

command. { { A more technically accurate name for this command would have been TPM2_StartSession. }} The session being started might never be used for authorization.

• Another case is password authorizations. Technically these are sessions, but no state is maintained between subsequent commands, and TPM2_StartAuthSession isn't used to start a password “session”. A password authorization is a one-shot authorization that applies to only one command.

The reason for noting these aspects is to help you comprehend the specification. Understanding the distinctions between these blurred usages of terms helped me as I was struggling to understand these concepts. As a result, I developed diagrams to help categorize the various types of authorizations, sessions, and session modifiers. Hopefully these will help you, too.

Figure 13-1. Authorizations and sessions Venn diagram

The following points are of special note in this diagram:

• Authorizations can be password, HMAC, or policy authorizations.

• Password authorizations can never be used for session use modifiers.

Note

in Figure 13-1, audit, encrypt, or decrypt are the only session use modifiers

shown, but there are others. these three are shown because they're the more commonly used ones.

• HMAC and policy sessions can be used for authorizations but can also be used to set session-use modifiers apart from any authorization. This why the HMAC and policy sessions straddle the authorization circle's boundary.

• The command's authorization area is where all of these authorizations, sessions, and session modifiers are specified.

• Command modifiers can be used in sessions used for authorization as well as those that aren't, which is why the audit, encrypt, and decrypt circles straddle the authorization circle's boundary.

• Sessions that aren't used for authorization can also be in the authorization area of the command and response byte streams.

• Policy sessions can be used for encrypt or decrypt, but not for audit. [2]

• HMAC sessions can be used for encrypt, decrypt, and/or audit.

Figure 13-2. Authorizations and sessions block diagram

Figure 13-2 illustrates the relationship somewhat differently. Note the following points in this diagram:

• The authorization area can specify the parameters for password, HMAC, or policy sessions. The authorization area is described in detail in the next section.

• Sessions started with the TPM2_StartAuthSession command can be HMAC, policy, or trial policy sessions.

• HMAC sessions can be configured on a per-command basis to be audit, decrypt, and/or encrypt sessions.

• Policy sessions can be configured on a per-command basis to be decrypt and/or encrypt sessions. They cannot be used for audit.

• The four session initialization variations can apply to HMAC, policy, or trial policy sessions.

The important things to remember are that sessions are the vehicle for authorizations but can also be used apart from any authorizations for per-command actions that are set by session modifiers.

Regardless of how the sessions are used or the type of authorization, if any, the command and response authorization areas are used to communicate the authorization and session data to and from the TPM. Before I describe the details of command and response areas, you need to understand the functions of authorization roles.

  • [1] A more technically accurate name for this would have been the sessions area.
  • [2] According to the TPM 2.0 specification developers, this was an optimization and not due to any fundamental technical difficulty.
 
< Prev   CONTENTS   Next >

Related topics