Digital Identity Working Group Service Credential Design 07

Digital Identity Working Group Service Credential Design 07 June 2018

Digital Identity Service Credential (M 2 M) Objective The purpose of this engagement with the Digital Identity Working Group, is to progressively work through a 5 step design plan that aims to deliver a functional machine to machine (M 2 M) solution for business, as part of an AUSkey replacement. Collaborative design of the end product is required to meet the following objectives: Adhere to industry established design principles in lieu of best practice Support functional & non-functional component requirements Meet all high and detailed level design specifications Support industry recognised use cases and scenarios Provide an alternative credential choice for AUSkey reliant entities UNCLASSIFIED –Digital Identity Working Group 2

Digital Identity Service Credential (M 2 M) Solution Plan TBD Commenced Complete Ste p 0 1 Ste p 0 2 Ste p 0 3 Ste p 0 4 Ste p 0 5 Design Principles Use Cases Component Requirements High Level Design The first step will involve the establishment of design principles that will underpin the development of a M 2 M solution – this will be achieved through collective agreement with the DSPs This step will look to focus upon recognising viable industry use cases that exist today, which will remain important to support moving forward – DSPs will be queried to supply relevant use cases that they deem critical for business and are therefor crucial to the next M 2 M solution Having already tested the current irritants in the AUSkey environment with DSPs the second step will look to capture product requirements necessary in any replacement solution With the collaboration made in the initial steps of this plan, the group should now be well placed to gather design evidence in order to develop a functional high level design that should demonstrate how the new M 2 M solution / product will work The culmination of all work carried out in this plan should allow the group to delve into detail level design which will be required to influence the operational build of a BETA solution and the required architectural plan UNCLASSIFIED –Digital Identity Working Group Detail Design These steps can be performed in tandem or opposing order 3

Service Credential (M 2 M) Principles & Requirements

Digital Identity Service Credential (M 2 M) Design Principles The following set of high level design principles were developed in collaboration with industry developers to support delivery of a new M 2 M solution. PRINCIPLE COMPONENT DEFINITION 1 Security • • • A system that supports end to end encryption for maximum security and privacy. A system that supports end to end receipts (end system not server based) where e 2 e encryption applies. End to end messages should be signed to support non-repudiation. 2 Extensibility • • Designs to remain open and flexible as possible. Keeping designs to a standards based arrangement. The authentication solution should support a messaging system with store and forward. A system that keeps the message and payload separated. The solution must support all messaging models. (e. g. point to point / multi-hop) The authentication must work across the agreed protocols. The solution must support new credential providers that choose to enter the network. 3 Compatibility • • The design must remain agnostic to existing and new frameworks in the industry. (e. g. Ops Framework / TDIF) The design must support a compatible transition of existing AUSkey systems and processes in the market. 4 Accessibility • • The M 2 M product must be made available on all current marketable channels and devices. The operational design of the service must be highly resilient. 5 Availability • Business operations must still be capable of functioning regardless of unforeseen disaster scenarios to the authentication system. 6 Scalability • • The system must be able to scale in an automated fashion up to foreseeable sizes. The system should be designed to scale. 7 B 2 B • M 2 M design must support the B 2 B environment. UNCLASSIFIED –Digital Identity Working Group d n E d e s or 5

Digital Identity Service Credential (M 2 M) Design Principles Continued … PRINCIPLE COMPONENT DEFINITION 8 Provisioning • • A person with a strong verified identity, is proven to have authority over the entity to then create a credential on behalf of the business service/entity. The entity that is assigned the credential must be vigorously identified by proof of entity not proof of human. The system must support full lifecycle management of the credential. (e. g. renewal / revocation). The solution must support self service. 9 Identification • • The system will support a label that represents meaning of identity to the associated entity. (e. g. email / URL) The system will support unique identifiers for the credential. 10 Legal • The solution should meet the relevant legal requirements that impact the service environment. UNCLASSIFIED –Digital Identity Working Group d e s or d n E 6

Digital Identity Service Credential (M 2 M) Design Requirements The following set of high level system requirements were developed in collaboration with industry developers to support the delivery of a new M 2 M solution. REQUIREMENT COMPONENT TYPE DEFINITION 1 General Non-functional • Review name of the M 2 M credential to consider change from the user based identity and credential product (my. Gov. ID). 2 Security Functional • • • The system solution must provide multi-factor. The M 2 M solution must maintain a service audit logging function forensic and legal purposes. The solution must support a government issued PKI system. 3 Authorisation Functional • • The system must allow authorised agency staff to manage an account on behalf of a user. The system must allow regular aggregate reports to be queried on device accounts for activity. (This includes functionality such as: view account history, update details) 4 Availability Functional • • The M 2 M service must maintain high availability (99. 95%). The M 2 M service should maintain a ZERO outage policy for planned servicing. 5 Accessibility Functional • The M 2 M solution must support installation on all common existing non-market platforms/devices including servers, desktops, laptops, smartphones and related mobile devices. 6 Scalability Non-functional • The M 2 M service capacity must support high volumes and concurrent use. 7 Compatibility Functional • my. Gov. Id will support modern operating systems such as Windows, Linux, OSX, i. OS and Android. 8 Mobility Functional • The system must provide users the ability to manage their registered credentials (This includes view add and remove credentials). 9 ID Lifecycle Functional • • The M 2 M solution must allow users to cancel the account(s) linked to their token device. Device management must be performed with equal or higher strength to the currently enrolled credential. UNCLASSIFIED –Digital Identity Working Group d e s or d n E 7

Service Credential (M 2 M) Server Side High Level Design

SERVER SIDE - Design 1 B 2 B CMS or SOAP Use Case UNCLASSIFIED –Digital Identity Working Group 9

SERVER SIDE – Design 2 SBR 1, 2 and SOAP Use Case UNCLASSIFIED –Digital Identity Working Group 10

SERVER SIDE – Design 3 REST Services Use Case UNCLASSIFIED –Digital Identity Working Group 11

SERVER SIDE – Design 4 Multi-Hop Use Case UNCLASSIFIED –Digital Identity Working Group 12

Service Credential (M 2 M) Client Side High Level Design

CLIENT SIDE – Discussion points my. Gov. ID Client SDK Needs Tech Stack Certificates/Key Materials • Standardised implementation for ATO user app across platforms • Lower barrier to entry for those unfamiliar with PKI / protocols • Simplify integration of my. Gov. ID usecases into client code Reference implementation for some/all user cases • Legacy support for AUSkey enabled client applications: SBR; CAA • TBD: Use of SDK is optional OR enforced via T&C • TBD: Open source • Platforms: i. OS, Android, Desktop (Linux, Mac, Windows) • C with native bindings for: • Priority 1: Swift (i. OS), Java, C# • Priority 2: Android NDK, PHP, Chrome, Node. JS • Priority 3: UWP? • Core dependencies: • open. SSL 1. 1+ • xmlsec 1 (for STS and XML canonicalization) • Keystore format: • JSON • TBD: meta-data • Salts: including for pbkdf 2 • Subject DN. TBD: • C=AU, O=<ABN>, CN=<user supplied> • Use of Subject Alt Name • No non-standard/custom extensions • Policy – OCSP support • RSA with keylen 2048 • PBE using PKCS#5 v 2 sha 2+ • Sign/Encrypt • Key usage: Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment • Encryption for transient data only. No escrow requirements • Preserve previous key • CMS support: Compress -> Encrypt > Sign • TBD: TPM Export UNCLASSIFIED –Digital Identity Working Group 14

CLIENT SIDE – Discussion points my. Gov. ID Client SDK Credential Management / Use • • • API to access keystore Platform independent custom keystore format Multiple credentials per keystore One password per keystore Meta-data: replicate some certificate data, additional data API main functions: delete, change password, password policy, create, install, renew (, send? ) Create/Renew to support async requests TBD: Create/Renew server operation • Verified by user credential • Publish to Public register TBD: API other functions: revoke, CRL/OCSP check TBD: All remote calls available via REST UNCLASSIFIED –Digital Identity Working Group Support for “higher level” use cases / protocols • Support G 2 G/B 2 G STS (SAML) using an XML template • Support for S/MIME, JWT • Support for exporting crypto material where possible: p 12, P 8, etc 15

CLIENT SIDE – Discussion points Current API Init() AKM: Keystore keystore = create. Keystore(buffer) keystore. change. Password() keystore. save() credential = keystore. get(alias) credentials = keystore. get() keystore. add(credential) STM: STS stm = create. STM(template) stm. set(. . ) st = stm. issue(certificate, privatekey, relyingparty, . . ) st. is. Expired() st. attribute() • attribute = rstr, prooftoken, assertion, samlid, AKM: Credential value = credential. attribute() • attribute = alias, type, abn, serial. Nr, subject. DN, issue. DN, not. Before, Cvalue = credential. crypto(password) • crypto = p 12, certificate, privatekey, sdata = credential. sign(password, data) credential. is. Current() P 10 = credential. renew. Request(password) p 7 = send(p 10) credential. renew. Process(p 7) UNCLASSIFIED –Digital Identity Working Group deinit() 16

Industry provided M 2 M Use Cases

Machine 2 Machine Use Capture In anticipation of the next event, we invite the group to provide relevant high level M 2 M use cases deemed important to your organisation that will be used to support solution design Highly secure and private B 2 B messaging Using: • End-to-end AS 4 messages • End-to-end encryption for payloads • End-to-end non-repudiation using read receipts. UNCLASSIFIED –Digital Identity Working Group Important: • The end businesses have a credential e. g. (SSL) or (S/MIME) signed by a world recognised CA (e. g. Digicert, Let’s Encrypt etc). • The AS 4 messages are signed. • The payload uses CMS which is compressed, encrypted and signed. • Gateways do not modify messages but deliver them. • Each MHS supports “multi-hop”. • Receiver sends back a signed read-receipt. 18

Machine 2 Machine Use Capture In anticipation of the next event, we invite the group to provide relevant high level M 2 M use cases deemed important to your organisation that will be used to support solution design M 2 M Digital Hierarchy Using: • Proof of ABN / Organisation • Not proof of identity i. e. human UNCLASSIFIED –Digital Identity Working Group Examples: • A device AUSkey may have a “subject” like “C=AU, O=11000703613, CN=Jekode 123”. For the ATO, presumably the whole subject is significant because you verify it in Access Manager. But in B 2 B, it’s the organisation that is significant, in this case, the ABN. • An S/MIME certificate where the organisation is obvious from the host. E. g. “joe@mycompany. com. au”. • An SSL certificate where the hierarchy may be conveyed via subdomains. E. g. “freds. mycompany. com. au”. For B 2 B, this could signify that “Fred's” is an identity which has been verified (vouched for) by “mycompany. com. au”. 19

APENDIX - AUSkey Key Findings

Digital Service Providers authentication and identity key findings Overview There are 1. 3 million AUSkeys that relate to just over 700 unique businesses Key finding themes Security of AUSkey is alright – allows us to sign the payload and message and provides a good base level of tamper proofing and initial security. Digital signatures should be considered given the amount of data. End-to-end encryption is critical, and we need to sign the payload which requires some kind of certificate. AUSkey uses x. 509 which is susceptible to brute force and rainbow table attacks. Passwords are set by the end user, making it susceptible to dictionary attacks. Machine-to-machine requires a different security model to person-to-machine. Users are familiar with AUSkey and comfortable with using it now, change management will be crucial for any AUSkey replacement Must work with the DTA, to consider a Wof. G B 2 G perspective as well as looking at B 2 B User experience and common error The user interface and experience needs to be improved. It’s difficult to set-up an AUSkey, and the access manager process is a disaster. AUSkey is limited to a PC or USB stick Users are unaware they need to change authorisation permissions in Access Manager for PLS. In addition, A small number of users cannot execute PLS lodgments at all. Businesses are unaware of or forget, that they have to manage AUSkeys and remove the old AUSkeys of previous employees. Many people do not have the technical knowledge for setting up an AUSkey correctly for what they need. Industry best practice One trusted source. Rather than pushing data which the ATO may not have the capacity to receive, store data in a secure server for the ATO to pull from. Integrate this work with the DTA projects around identity. Public registry of public keys. A single access point of verification, useful for B 2 B and B 2 G The STP authentication model is ‘not there yet’ The UK HMRC authentication is an example of progressive machine based authorisation Consider NPP using the same solution – don’t use AUSkey to sign but to authenticate a connection for certain data Consider 3 rd party integration - current authentication model does not fit well with 3 rd parties

Recommendations Maintain security integrity of AUSkey • Ensure end-to-end encryption • Use alternative to SHA 1, to reduce risk of brute force and rainbow table attacks Improve the user experience and reduce likelihood of common errors • Improve Access Manager UI • Guide users in setting up credential and ensure they understand their privileges • Management integrity, notifying users about inactive credentials, and implement an easy to use system to remove them Implement best practice technology solutions • A consolidated approach encompassing B 2 G and B 2 B

Recommendations Current state Business Individual on behalf of one or more businesses AUSkey is linked to the ABN. An individual acting on behalf of multiple businesses will hold multiple AUSkeys, one for each entity they act. Manager for. Access is difficult to use, and once set-up admin AUSkey holders do not use it unless there is a need to. Maintenance of AUSkeys are often overlooked as they do not login and use Access Manager regularly. • Admin user AUSkey • Standard user AUSkey • Device AUSkey (via software) Governmen t Individual identity is known Individual identity is unknown Future desired state Governmen t B 2 G Individual on behalf of one or more Single login allowing the businesses individual to act on behalf of multiple businesses How does authentication work? ATO Server One authentication for B 2 G and B 2 B Software End-to-end encryption using digital signatures. DSP pushes data to a secure server, B 2 B Business Principles for authentication key, set-up and process Improved User Experience Secure Easy to set up and manage Flexible Guide users in setting up credential and ensure they understand their privileges, and maintenance responsibilities Clear information on where they are in the process and what is required Clear information about what happens with their information End-to-end encryption, using digital signatures. Sense of certainty their personal information is safe and secure Ability to segregate functions and roles. Provide access based on roles rather than individuals to ensure continuity of access when people move in and