 COEL-TC Call (Conference Call) |
|
| Name | COEL-TC Call (Conference Call) |
| Time | Tuesday, 28 July 2015, 01:00pm to 02:00pm UTC
(Tuesday, 28 July 2015, 01:00pm to 02:00pm UTC) |
| Description | Pass code: 46620642 United Kingdom 08000234295 02076351808 +44 2076351808 Australia 1800004583 0282239344 +61 282239344
|
| Minutes | Review of COEL Ecosystem document We agreed the approach to security was coherent and sensible with no obvious holes.
Review of actions
[2015-07-21 / 1] David: Create Issues in OASIS issue tracker from outstanding issue list document. TO BE COMPLETED [2015-07-21 / 2] Paul: Verify that the IDA specification captures the "Need a standard format for Operators and Service Provider identifiers" DONE [2015-07-21 / 3] Paul: Present security options for ecosystem at next call. Post an email for discussion to COEL list.(to include privacy contribution from Joss) DONE [2015-07-21 / 4] David to lead discussion at next meeting on Schedule for publishing drafts. DONE [2015-07-21 / 5] David: Make requests to OASIS to create document folders: "Documents/Submissions" and "Working Drafts/COEL Model" DONE
|
| Agenda | We agreed last week to review the latest security topics. See below: [1] Use SSL for all internet communications within the ecosystem. This creates an encrypted channel for the data (Atoms, Reports and Pseudonymised Keys – no DIPI) and prevents a third party from reading it in transit. It means that servers like the IDA, Data Engine and any Service Provider/ or Operator systems must have SSL certificates (between £100 and £300 pa cost or see https://letsencrypt.org/) [2] Use single factor authentication (user-id and password) for all Data Engine and IDA calls with the exception of: [a] submitting atoms which can be done anonymously [b] an operator registering consumers with the DE (see below for why) [3] Use IDA generated pseudonymous keys as the user-ids for actors in the ecosystem. These are devoid of DIPI and unique across the ecosystem. [4] Use different user-ids AND different passwords for each embodiment (e.g. for Operator with IDA, Operator with DE, Service Provider with different DEs etc) Let’s look at the systems/interactions to see what the threats are: [1] Operator / IDA: Disclosure of M2M credentials would allow an attacker to generate Pseudonymous Keys on behalf of an operator. There is no possibility of disclosure of DIPI or behavioural data. Risk is low. [2] Service Provider / IDA. Disclosure of SP interactive login would allow attacker allocate new OperatoIDs or disable existing OperatorIDs. The IDA will not keep any DIPI for operators and their IDA passwords are stored encrypted so there is no risk of these being disclosed. If an attacker gains access then the Service Provider will need to change their password and re-register its operators. [3] Operator / DE: Disclosure of operator credentials would allow an attacker only to register consumers as the operator has no other role with the DE. With this in mind Matt and I agreed that there is no need for an operator password when registering a consumer with the DE. Registering is similar to submitting an Atom. [4] Service Provider / DE: This is where the highest threat is. Disclosure of credentials that gave access to the Data Engine Management Interface (MI) and Query Interface (QI) would open up two possible attacks: [a] An attacker can query the tree of operators and consumers (via MI) and then retrieve all Atoms for all consumers for the SP (via QI). [b] An attacker can use the MI to issue ‘forget’ requests for consumers. This would result in either deleting all the atoms, or disconnecting the atoms from their original consumer ID. It would render the atoms useless to the SP because by definition these are not reversible. To reduce the likelihood of [a], we should mandate that separate credentials be used to access the MI and QI, reducing the likelihood of getting both. To reduce the likelihood of [b], the data engine must use a secondary method to assert the identity of the service provider. Forgetting is a rare event and insisting that there be a human in the loop will make it more secure. We can mandate that the DE send an authorisation email to the SP asking it to confirm the forget request. (Unlikely attacker has access to this mailbox). Or the DE can mandate a second factor of authentication for forget requests such as a handheld RSA key [5] Operator/SP. Where the operator is a separate entity (such as in the GP/AI scenario), it will request reports on consumers from the SP, but these reports are pseudonymised so contain no more information than the query returned from the DE. The operator adds in the DIPI itself. Low risk. |
| Submitter | Dr. David Snelling |
| Group | OASIS Classification of Everyday Living (COEL) TC |
| Access | This event is visible to OASIS Classification of Everyday Living (COEL) TC and shared with
|