A Model for New Zealand’s Identity Verification Service

1. A Model for New Zealand’s Identity Verification Service Prof. Clark Thomborson Trust 2008 Villach, Austria 11th March 2008

2. Objectives of this model • To study identification in a hierarchy, in a peerage, and in an aliased relationship. • I believe these three types of relationships are of crucial importance in trusted computing. • To develop a simple yet meaningful model of a complex identification management system. • Case study: New Zealand’s Identification Verification System • To distinguish three types of authentication: • “What you have”, “What you are”, and “What you know”. NZ IVS March 2008

3. The CEO Model • Credentials • Entities • Observations • An entity can disclose a self-signed credential, revealing its signing key. • Entities can observe their inferiors and aliases. • Entities reveal information about other entities to their superiors and aliases. NZ IVS March 2008

4. Three Types of Relationships • Hierarchical: A superior observes its inferiors. An inferior entity discloses “everything” to their superior. A superior discloses only its signing key to its inferiors. • This is a Bell – La Padula system. Superiors do not disclose to inferiors. Inferiors can not observe superiors. • Peering: A peer does not disclose their personal identifiers to other peers. Peers cannot observe each other. • Peers share an pseudonym: their Peer Identifier. • Peers can vote anonymously. • Organisations (whether hierarchical or peering) can communicate via any entity which has an alias in each organisation. • Aliased entities managed the “bridging relationships” defined in my previous writing. • Aliases are observable. Our aliases will publish credentials to their superiors, and are thus a security risk to a confidential hierarchy. NZ IVS March 2008

5. The Hierarchy • Information flows upwards, toward the most powerful actor (at the root). • Commands and trustflow downwards. • The King is the most privileged. King, President, Chief Justice, Pope, or … Peons, illegal immigrants, felons, excommunicants, or … • The peons are the most trusted. • Information flowing up is “privileged”: allowed by default, might be required. • Information flowing down is “trusted”: prohibited by default. • See TCSEC (Orange Book): LOCKix. NZ IVS March 2008

6. The Alias (in an email use case) • We use “aliases” every time we send personal email from our work computer. • We have a different alias in each organisation. • We must be careful what information we disclose about our organisations, and what information we introduce into our organisations. AgencyX Hotmail C, acting as a governmental agent C, acting as a hotmail client • An aliased relationship is bidirectional trusted. Each of our aliases is in a different security environment. NZ IVS March 2008

7. Another Example: B2B e-commerce • Use case: employee C of X purchasing supplies through employee V of Y. • Employee C creates a hotmail account for a “purchasing” persona. • Purchaser C should reveal minimal information to V. Company X Company Y Employee V C, acting as an employee C, acting as a purchaser • Most workflow systems have rigid personae definitions (= role assignments). • Current operating systems offer very little support for aliases, other than virtualisation. Important future work! NZ IVS March 2008

8. The Peerage • Information flows upwards by default (“privileged”). • Commands and trust flow downwards. • Downward information flows are “trusted” (filtered, audited, etc.) • A peerage can be modeled by Bell-La Padula, because there is a partial order on the actors’ privileges. • Peers can vote anonymously. Peers, Group members, Citizens of an ideal democracy, … Facilitator, Moderator, Democratic Leader, … • Equality of privilege is the default in a peerage, whereas inequality of privilege is the default in a hierarchy. NZ IVS March 2008

9. Example: A Peerage Exerting Audit Control on a Hierarchy • Peers vote on their officers, including at least one Inspector-General. • The OS Administrator makes a Trusting appointment when granting auditor-level Privilege to an alias of an Inspector-General. • The Auditor should disclose a report to their Inspector-General alias. • The audit report can be read by any Peer. • Peers might disclose the report to non-Peers. OS Root Administrator Auditor Users/ Peers Inspector-General (an elected officer) IG1 IG2 Chair of User Assurance Group NZ IVS March 2008

10. Application to Identity Management • The system on the preceding slide has very complex security objectives. • Each entity has complex capabilities, privileges, and trusting relationships with other entities. • See the ECO extension of Secure Tropos (Giorgini et al., 2006). Roughly: “privilege” = “entitlement”. • I don’t want to get bogged down on TC UAGs here, but let’s talk offline if you want to help me create one! • The CEO model is greatly simplified. • CEO entities have very simple privileges, trusts, capabilities, and objectives – suitable only for identity management systems. NZ IVS March 2008

11. Observations in the CEO model • Hierarchical: a superior can observe its inferiors, but an inferior cannot observe its superior. • A superior has just one privilege: it can see the “observable identity” (ObId) of all inferiors. • Application: a surveillance camera in a workplace can collect biometric data on all employees and visitors. • Peering: a peer cannot observe its peers. • Peers share a Peer Identity (PeerId) but are otherwise anonymous. • There are two types of entities. • Active entities can observe the ObId of all their aliases, and will disclose this information (in a credential) to their superior. • Passive entities can be observed, but cannot disclose credentials. • Application: our identification tokens are active aliases. • Application: any database record that contains one of our identifiers is a passive alias. NZ IVS March 2008

12. Disclosures in the CEO model • Hierarchical: inferiors disclose their PeerId to their superior. • Alias: active entities observe the ObId of all their aliases. • Alias: active entities disclose “everything they know” to their other aliases. • Hierarchical: inferiors disclose “everything they know” to their superior. • A CEO model of an identification management system • will help us explain it; • will help us figure out “who learns what” (identification vs. preservation of anonymity); • will help us prove that its credentials guarantee a uniqueness property. NZ IVS March 2008

13. Crown NZ’s IVS • A citizen can have at most one Verified ID (VID) at each agency. • Anonymised IDs can be created. • Session IDs are transient. DIA SA1 SA2 IVS GLS Referee Citizen igovtVID igovtUVID DIA Id IVS VID VID for SA2 VID for SA1 SID for SA1 SID for SA2 SID for SA2 Anon at SA2 VID at SA1 VID at SA2

14. Did I meet my objectives? • To study identification in a hierarchy, in a peerage, and in an aliased relationship. • Do you understand these relationships? (Do you agree that they are crucial in trusted computing?) • To develop a simple yet meaningful model of a complex identification management system. • Do you understand how New Zealand’s Identification Verification System would provide semi-anonymous and semi-unique credentials? • To distinguish three types of authentication. • Do you believe that the CEO model could distinguish “What you have”, “What you are”, and “What you know”? NZ IVS March 2008