Draft
ETSI TR 103 304
V0.0.2

2 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Reference
DTR/CYBER-002
Keywords access control, privacy
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
SousPréfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from: http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
Reproduction is only permitted for the purpose of standardization work undertaken within ETSI.
The copyright and the foregoing restrictions extend to reproduction in all media.
© European Telecommunications Standards Institute 2015.
All rights reserved.
DECT TM , PLUGTESTS TM , UMTS TM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
3GPP TM and LTE ™ are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
GSM
® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

3 Draft ETSI TR 103 304 V0.0.2 (2015-05)
ETSI

4 Draft ETSI TR 103 304 V0.0.2 (2015-05)
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members , and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server ( http://ipr.etsi.org
).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
This Technical Report (TR) has been produced by ETSI Technical Committee Cyber Security (CYBER).
In the present document " shall ", " shall not ", " should ", " should not ", " may ", " may not ", " need ", " need not ", " will ",
" will not ", " can " and " cannot " are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
" must " and " must not " are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI

5 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Essentially different than any previous telco scenario where user data was accessible from network functional elements only, today even sensitive Personally Identifiable Information (PII) is directly accessible from terminals. Server-based data access control technologies are becoming less effective for PII protection.
The present document is intended to describe novel access control technologies that enable:
1) data protection, based on policies, as soon as data leaves the boundary of a trusted (terminal-based) environment;
2) respect of policies during the data life cycle;
3) portability of protection settings when data moves from one service provider to another (and, implicitly, their interoperability),
4) efficiency, also with regards to low-resources devices
References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at http://docbox.etsi.org/Reference .
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
[i.1] Article 29 Data Protection Working Party.
NOTE: Available at http://ec.europa.eu/justice/data-protection/article-29/press-material/pressrelease/art29_press_material/20141126_wp29_press_release_ecj_de-listing.pdf
.
[i.2] National Institute of Standards and Technology NIST SP 800-122: "Guide to Protecting the
Confidentiality of Personally Identifiable Information (PII)".
NOTE: Available at http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
.
ETSI

6 Draft ETSI TR 103 304 V0.0.2 (2015-05)
For the purposes of the present document, the following terms and definitions apply:
Personal Data: any information relating to an identified or identifiable natural person ('data subject');
Data subject: an identifiable person, i.e. a person who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity.
PII principal: natural person to whom the personally identifiable information (PII) relates [ref ISO 29100].
Personally Identifiable Information (PII): any information that (a) can be used to identify the PII principal to whom such information relates, or (b) is or might be directly or indirectly linked to a PII principal [ref ISO 29100].
Any information about an individual maintained by an agency, including any information that can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother's maiden name, or biometric records; and any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information [ref NIST SP 800-122].
PII controller: privacy stakeholder (or privacy stakeholders) that determines the purposes and means for processing personally identifiable information (PII) other than natural persons who use data for personal purposes.
PII processor: privacy stakeholder that processes personally identifiable information (PII) on behalf of and in accordance with the instructions of a PII controller.
Metadata: are data about the data, might be structural or descriptive.
Processing of personal data: any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction.
Consent: any freely given specific and informed indication of his wishes by which the data subject signifies his agreement to personal data relating to him being processed.
For the purposes of the present document, the following abbreviations apply:
PII
OS
BYOD
PIN
XACML
SAML
PMI
CSP
CSPa
CSC
UC
AC
ABAC
ABC
LI
API
TE
GUI
CEO
Personally Identifiable Information
Operating System
Bring Your Own Device
Security Assertion Markup Language
Cloud Service Provider
Cloud Service Partner
Cloud Service Customer
Use Case
Access Control
Attribute-Based Access Control
Attribute-Based Credentials
Lawful Interception
Application Programming Interface
Terminal Equipment
Graphical User Interface
Chief Executive Officer
ETSI

7 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Editor’s note: Protection of PII is a difficult problem because: very large topic, lack of well-defined scope, lack of shared view on what personal data is (a property, a moral right, something like a trade secrecy?). Here addressed from a technical PoV. All kinds of methods can be used to limit the collection of and access to personal data. However... ]
In traditional telecommunications regulatory aspects protecting PII are present. Directive 95/46/EC (data protection), directive 2002/58/EC (privacy), and Directive 99/5/EC (radio equipments), for instance, state the legal obligations to preserve a user's control of their identity in electronic communication, and to avoid frauds.
Properly using identifiers and identity management as suggested in [ref TR187 010] massively reduces the risk to exploit of PII in communication signalling. However, as we move towards a genuinely distributed and virtualised (e.g.,
Cloud-based) environment characterized by a rich set of services available to users, it may be difficult to have a priori knowledge of who may need access to data that could be PII.
PII in long term data records (such as health, public administration, financial and legal sectors) are dynamic and grows over the life of an individual. The set of actors/individuals/roles that need to access and amend it over a lifetime is potentially unlimited. It is also not reasonable to expect the record to be “a single document” rather it will likely appear as a large set of documents, managed by various (perhaps not fully trusted) distributed systems, containing several cross references to other records. In such records there may be a need to enable access controls of some complexity.
The present document is intended to describe novel access control technologies that enable:
1) data protection, based on policies, as soon as data leaves the boundary of a trusted (terminal-based) environment;
2) respect of policies during the data life cycle;
3) portability of protection settings when data moves from one service provider to another (and, implicitly, their interoperability),
4) efficiency, also with regards to low-resources devices
The rest of the present document is organized as follows:
- clause 5 describes…
…
Threats derived from scenarios reported in Annex A are presented in the following text.
Data from different sources, which are typically designed for specific and limited purposes, may be merged and analyzed through several different techniques. This process, known as data fusion [ref PCAST], may lead to discover information which were not originally present or evident looking at the original sources. In the contest of web applications, tracking cookies (particularly third parties tracking cookies) may facilitate this process. De-anonymization may be one relevant consequence. This process might not be evident to the data subject.
Cloud or remote storage offers several advantages in terms of availability (data is no longer dependent on the device used to create it and manage it). However, cloud computing storage at large date centers may increase the risk of temporary inaccessibility or even large losses of personal data, because of network connection issues, shortages or server failures. Normally terms of service contain clauses which address the aforementioned problems (generally
ETSI

8 Draft ETSI TR 103 304 V0.0.2 (2015-05) providing backup/disaster recovery solutions). However, this does not prevent that services might be terminated at any time due to non technological problems, e.g. bankruptcy of the provider or legal reasons (as happened to some very popular file-sharing portals). Localization of the service provider may be a relevant aspect – as the service may be subject to different regulations and laws.
Normally the CSP operates with a B2B agreement with a CS partner to provide services to users. For example the CSP might choose to rely on a storage CSP as a partner (as such, the partner plays the role of PII processor). Users may trust the CSP (PII controller) but not necessarily the CS partner, e.g. due to its localization. Risk connected with this threat are disclosure, manipulation, inaccessibility. Cryptography and access control techniques may be used to ensure proper confidentiality, integrity and availability of data.
Ransomware is a particular category of malware which silently encrypts content store inside a TE or on remote storage connected to the TE usually by asymmetric cryptography. As a result, documents, images, and other kind of data are no more available to the user unless he proceeds with the payment of a ransom. Installing vetted software from a trusted source is a general measure to prevent malware. Additional access control mechanisms may apply as a specific measure for ransomware.
A different form of unavailability may be introduced by lock-in mechanisms. Lock-in prevents portability and interoperability of customer’s data across different providers. As a result, when a customer decides to change provider, data in his or her account may be made simply unavailable or get lost.
Editor's note: From scenario: Social Networking App. Impact: TE. Related risk: Disclosure. Security Property:
Confidentiality
Over-collection occurs when a computer program intentionally, but not necessarily clandestinely, collects information unrelated to its stated purpose. Over-collection, when present, is intentional for information “born digital”, i.e. information created specifically for use by a computer or a digital system (including meta-data). However it might be present by default when the information arises from the physical world and is captured by sensors, due to the difficulty to filter out signals not related to the scope of the program (so called “noise”). Applications referred to as “people as sensors” exploit over-collection to provide additional services to users. [Ref PCAST] Reports several examples and really happened cases of over-collections. Over-collection may lead to unwanted disclosure of PII.
Mis-contextualization occurs when data from different users or personas are mixed. It might be an unintentional event due to a missing reset of the terminal or to a missing account switch when the terminal is used by a second user. In some TE, despite multiple users account are supported, the GUI does not provide an easy way for users to switch between different accounts. The terminal may contain PII and pointers to online accounts which might not be easily deleted by the user. As a consequence, if the terminal is not properly reset when sold or stolen the account data may be accessed by unauthorized users, leading to disclosure of PII and identity theft.
The business model of some services requires users to consent to a number of uses of the data. The owner relationship or access rights may be altered when a document is released to the service. The document may be made public and even indexed in search engines. For example, when a user posts a photograph in a Cloud-based service, the user may
ETSI

9 Draft ETSI TR 103 304 V0.0.2 (2015-05) relinquish exclusive ownership. Terms of service normally contain clauses that refer to these uses, though sometimes they are transparent to the end user.
The Service Provider (data processor) generally owns the data concerning the users. However, in many Countries, PII are specially acknowledged so that the data subject maintains certain rights on them (for example, the right to knows which data are retained, the right to correct wrong information about them, the right of having data deleted after a period. [ref ] discusses this subject in details). Mechanisms able to mark PII with special meta-data should be put in place in order to distinguish PII from other kind of data.
Risks connected to this threat are: disclosure, manipulation, inaccessibility.
To ensure business continuity and prevent data loss, generally data centres provide by default security policies such as backup and replication over different nodes. This feature may introduce an alteration of natural data persistence compared to local storage. Secure data deletion, required, e.g. by a service termination or willing of customer to exit the process might be difficult to ensure, without the ability to resort to destruction of the hardware.
Though cryptography could provide a mean to ensure confidentiality when data is stored on a remote location, it is not equivalent to physical security. At the present time, no technology option seems suitable to ensure information extinction after its disclosure (a desired feature referred to as the right to be forgotten in some legal contexts). The safest assumption is to assume that data, once released and disclosed will be persistently present in the Cloud [ref ].
The four main risks identified in the present document are: disclosure, inaccessibility, destruction, manipulation.
Threats sources may include accidents, natural disasters, humans authorized or unauthorized to access data and systems.
Table X.X -
Scenarios Use Case
UC2
Risks
Disclosure
Threats Vulnerabilities Security
Properties
Over-collection Permissions Confidentiality Social
Networking
App
Installing untrusted
APPs
BYOD,
Social
Networking
App
Social
Networking
App
UC2
UC2
UC2
Cloud
Unavailability
UC1
Inaccessibility Ransomware
Disclosure
Disclosure
Data sharing
Data fusion
Permissions Availability
Permissions, no way to extend access control outside TE
Confidentiality,
Accountability,
Authentication
Changed scope/use
Accountability,
Confidentiality,
Authentication
(Unlinkability)
Remote
Storage
Availability
Social
Networking
App
UC2
Inaccessibility Service termination or inaccessibility
Disclosure,
Inaccessibility,
Manipulation
Access rights alteration,
Indexing in search engines
Loose ownership,
Changed scope/use
Confidentiality,
Integrity,
Availability,
Accountability
(right to be
ETSI

Social
Networking
App
UC2
Medical
Scenario
UC1
BYOD UC2
10 Draft ETSI TR 103 304 V0.0.2 (2015-05) forgotten)
Disclosure Altering normal persistence
Remote
Storage, replication
Disclosure,
Inaccessibility,
Manipulation
Untrusted infrastructure
(e.g. rogue processing nodes, localization, different legislation, et cetera)
Remote
Storage, replication
Accountability,
Confidentiality
(right to be forgotten)
Confidentiality,
Integrity,
Availability,
Accountability
(location control)
Disclosure,
Inaccessibility,
Manipulation
Miscontextualization, identity theft
Missing device reset or account switch
Authentication,
Confidentiality,
Integrity,
Availability,
Accountability
ETSI

11 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Actors are individuals or organizations which can play one or more roles.
Roles considered in the present document have been defined in [Ref CloudCoordinationFinalReport]:

Cloud Service Provider (CSP): The Cloud Service Provider role consists of those providing cloud services to one or more Cloud Service Customers. For the purpose of this deliverable, CSP may configure as a data processor.

Cloud Service Partner (CSPa): The Cloud Service Partner role consists of those providing support to the provisioning of cloud services by the Cloud Service Provider, or to the consumption of cloud service by the
Cloud Service Customer. For the purpose of this deliverable, CSPa may configure as a data processor.

Cloud Service Customer (CSC): The Cloud Service Customer role consists of those consuming one or more cloud services provided by a Cloud Service Provider.
Additionally, the following role is defined in [Ref CloudCoordinationFinalReport]:

Government authority (GA): The government authority role consists of those interacting with providers, customers and partners for the purpose of regulation, law enforcement, national security, inspection, economic stimulation, et cetera.
6.10.1 Use cases 1 (UC1)
CSC is an end-user service customer consuming the end user services offered by the CSP.
The CSP has an Agreement with a CSPa providing storage to store/access CSC data under a Service Level Agreement
(i.e., CSPa provides support to the provisioning of cloud services by the CSP)
CSCs are data subjects interacting with the service by using a computer application installed on a TE which processes their PII.
CSP configures as a PII controller.
CSPa configures as a PII processor.
6.10.2 Use case 2 (UC2)
CSC is an end-user service customer consuming the end user services offered by the CSP.
The CSP provides storage to store/access CSC data.
CSPa has an Agreement to access CSC data from CSP under a Service Level Agreement (i.e. CSPa provides support to the consumption of cloud service by the CSP).
CSCs are data subjects interacting with the service by using a computer application installed on a TE which processes their PII.
CSP configures as a data processor.
CSPa configures as a data controller.
Editor’s note: Typical scenario occurring with mobile phone, where user’s data is held in the Cloud storage of the OS provider and APPs from 3 rd party Service Providers requires access to user’sPII.
Editor’s note: need to explain GA’s impact on the two use cases.
ETSI

12 Draft ETSI TR 103 304 V0.0.2 (2015-05)
ISO/IEC 29100 [ref] provide a set of recommended privacy principles that should be follow, without or with limited exceptions, despite differences in national Countries. They include:
(Informed) consent and choice whenever applicable, including the ability for the PII principal to withdraw the consent and special provisions for individuals not legally able to express their consent and procedures by government authorities. Noticeable that, even if the consent is withdrawn, the PII controller may need to retain data for a given period for legal or contractual obligation
Purpose legitimacy and specification, including special provisions for sensitive PII which may be subject to specific law constraints
Principle of collection limitation: organization should not collect PII indiscriminately, and inform PII principals when collection of additional information (not specifically related to the provision of the main service) is optional
Data minimization, including removal of unnecessary processing and unnecessary access to PII and deletion of
PII whenever no more strictly needed for the provision of a service (or any legal obligation thereof)
Use, retention and disclosure limitation
Periodic verification of accuracy of information and quality of the processing, especially when inaccurately collected or processed data could result in harm to the PII principal
Principle of openness and transparency, including notices on the options available to the PII principal for accessing, correcting and removing or limiting processing of information; and detailed information on required
PII, purpose of processing, details of processing including types of authorized persons able to access the records, mechanisms of collection, storage, communication, retention and disposal procedures
Individual participation and access: give the PII principal the ability to access, review and provide any correction or request of removal of PII (subject to applicable law for specific cases)
Principle of accountability of processing and measures taken for protecting PII from privacy breaches and compensation in case of e.g. identity theft, reputation damages, PII misuse or accidental mistakes in the processing of PII
Implement information security to protect confidentiality, integrity and availability of PII from risks such as unauthorized access, destruction, use, modification, disclosure, loss throughout the whole data lifecycle
Principle of compliance with privacy (law)
<Text>
Because PII deserves a special treatment, identification of PII is an important preliminary step for all kinds of security mechanisms intended to protect PII. Due to the growing variety of services provided, identification of data tha may be
PII might be not easy. However, operating systems designed for modern terminal equipments typically have built-in security mechanisms that prevent new installed programs to automatically access certain kinds of resources accessible from the equipment - unless user’s explicit consent (provided through a “permission form”). These operating systems are able to distinguish and manage different classes of resources including data resources, and provide identifiers for them. Examples of data resources which are or may contain PII include:

Contacts

Sms/mms/voicemail/call logs

IMSI/IMEI
ETSI

13 Draft ETSI TR 103 304 V0.0.2 (2015-05)

OS settings/preferences

Bookmarks

Browser Search history

Calendar

Location

APN

Media files and other documents
Identifiers for these classes of resources may be provided in forms of URIs to facilitate interoperability between different systems.
Editor's note: e.g. transparency about which data is being collected and for what purpose at any time and place.
Editor’s note: how to authenticate without revealing user’s full identity?
Editor's note: Confidentiality: Data Erasing/rewriting e.g. factory reset for terminals. If confidentiality cannot be physical, then: encryption but with its limitation (data extinction is not guaranteed). Should look at issues relating to data erasure threats (inability to delete data on certain types of storage without resorting to destruction of the hardware).
[Scott]
Editor's note: Confidentiality: Should also look at existing asymmetric and symmetric key crypto architectures, and key agreement protocols. [???Scott].
Editor’s note: Availability: backup, replication, versioning…
Editor’s note: these challenges are taken from ETSI DTR 101 567, which describes LI/RD challenges in distributed
(Cloud-based) environments
- Service challenge: standardized LI solutions exist for voice, conferencing, IMS-based services; messaging (SMS, e-mail, etc); internet access. Most “new” services (file sharing, telepresence, social media, online games, etc) have no standardized LI solution, and in most countries, there are no existing regulations concerning these services.
- Cloud challenge: it is a fundamental requirement for LEAs to be able to identify and communicate with the service provider(s) responsible for the communications involving specific targets. It may be difficult to identify and communicate with the service provider(s) responsible for the communications involving specific targets in cloud environments because the relevant C(L)SP providers are often not subject to registration, regulatory, or CSP partnership requirements that facilitate discovery of their identity(ies).
- Encryption challenge: Media, data and metadata may be encrypted by many parties when transferred or stored. The service providers who initiate encryption should provide intercepted telecommunications en clair, or if they cannot remove the encryption, provide the LEA with the keys and other information needed to access the information where
ETSI

14 Draft ETSI TR 103 304 V0.0.2 (2015-05) such keys are available to the service provider [ref ETSI TS 101 331]. However, subscribers of services may encrypt the data prior to transferring it to the provider (end-user encryption) and prevent C(L)SPs from accessing their data.
- Target identification challenge: the target of lawful interception may have several different network or service identities, depending on the network or service provider and type of interception being accomplished. The identifiers used by the service provider and access network operator are typycally different and it may be difficult for the LEA to maintain the binding of the identifiers/addresses between the domains.
- Location challenge: TS 101 671 [ref] defines location information as “information relating to the geographic, physical or logical location of an identity relating to an interception subject.” The location at which users are using cloud based services may be difficult to discern in an assured manner.
- Nomadicity challenge: the subscriber’s ability to access their data and services from any device, especially devices with no known association (e.g., not owned) with the intercept subject complicates an LEA’s ability to initiate an access level lawful interception in a timely manner.
Portability applied to data as well as to meta-data avoids unavailability of data as a consequence of change of provider
(lock-in). When combined with protection, portability of protection settings may ensure that proper protection is still in place despite data is moved or replicated across nodes belonging to different providers or located in different countries.
Editor's note: Focus on Access Control. "Mission" or "Scope" based access control rather than AC based on accounts might answer the need of reasonably scope-limited handling of personal data.
Editor’s note: OoT Protocol [Scott]
Trust: formally trust is defined as the level of confidence in the reliability and integrity of that entity to fulfil specific responsibilities.

Trust is not a binary operation. There may be various levels of trust that an entity has for another.

Trust may be relative, not absolute. Alice may trust Bob more than Eve, without trusting either absolutely.

Trust is rarely symmetric and should never be made artificially so. Alice may trust Bob completely, whereas the amount of trust that Bob has for Alice may be very low. The pupil may trust the master without any requirement for that trust to be reciprocated.

Trust varies over time and the level of dynamism may also vary between different relationships.

Having a secured communications channel with another entity is never sufficient reason to trust that entity, even if you trust the underlying security primitives on which that communications channel is based.

Trust requires identification. If the scenario is one in which most of the actors are unknown to one another we need to provide means for parties to build up trust. In trust networks this is achieved through delegated relational trust.
ETSI

15 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Authentication may happen using a variety of mechanisms based on something which the user knows, has or is, including:

Gesture patterns

PIN

Passphrase

Username/password

Biometric characteristics

Attribute based credentials
Most authentication mechanism may require actual user identification. Attribute Based Credentials might provide authentication without revealing user’s identity ensuring respect for privacy.
Privacy Attribute-Based Credentials (Privacy-ABCs) are conceptually similar to attribute certificates, however have strong confidentiality properties.
Users obtain certificates with attributes related to them and use those certificates in transactions to authenticate (parts of) this attribute information. Only a subset of the attributes comprised in a certificate is revealed in each transaction. It is even possible to prove a property over an attribute without revealing it, e.g., prove that the date or birth attribute is more than 18 years in the past, in order to assert an age of at least 18 years to the recipient, without revealing the actual date of birth.
Privacy-ABCs have some additional properties that make them attractive for privacy protection. Specifically, Privacy-
ABCs are by default untraceable by all entities in the ecosystem. Entities issuing the credentials to users are not able to track and trace at which sites the user is authenticating. In addition, different transactions even on the same service provider can be cryptographically un-linkable to each other, making it impossible to track and profile the user.
Privacy-ABCs allow for balancing privacy with accountability, that is, it can be made possible that the full identity of users can be obtained by a specified party (Government Authority) in case of legal needs, national security purposes.
The Identity Mixer Privacy-ABCs technology is based on provably secure cryptographic protocols that have undergone validation through the cryptographic research community [Ref CL01]. Examples of Privacy-ABC implementations are
Idemix
1
and U-Prove
2
. Over the last few years, Idemix and U-Prove have been developed to offer an extended set of features, even though these features are named differently and they are realized based on different cryptographic mechanisms. In 2010, the EU research project ABC4Trust was initiated with the goal to alleviate these differences and unify the abstract concepts and features of such mechanisms. So, the ABC4Trust architecture has made it possible to define Privacy-ABCs in a way that is independent from the specific cryptographic realization beneath.
Cryptographic mechanisms related to privacy-ABCs have also been standardized in international standards covering generic primitives, e.g., by ISO [RefISO13], and also in the TPM specification 1.2 [RefTCG04], which has also evolved as an ISO international standard [RefISO09]. The relevant technology there is referred to as Direct Anonymous
Attestation (DAA) for privacy-preserving platform attestation. The upcoming version of the TPM also comprises related primitives for anonymous platform attestation. Both ISO/IEC JTC 1/SC 17 and ISO/IEC JTC1/SC 27 are currently working on standards specifically for privacy-ABC technologies, both for smart cards, as well as on the generic technology.
1 J. Camenisch and E. Van Herreweghen, “Design and implementation of the idemix anonymous credential system,” in Proceedings of the 9 th ACM conference on Computer and Communications Security (CCS ’02), 2002, pp. 21–30.
2
S. Brands, Rethinking Public Key Infrastructures and Digital Certificates; Building in Privacy. MIT Press, 2000.
ETSI

16 Draft ETSI TR 103 304 V0.0.2 (2015-05)
On an isolated terminal the assumption is that data is only available to the holder of the terminal. Normal assumption is that the holder is the data owner (principal or data subject). If this assumption is not guaranteed to hold then the principal may inhibit access (unlock pin or equivalent).
When remote storage is used the aim is to give assurance that only the owner/holder, and any other party authorized by the principal, can access the remote data. Derived from Identity-Based Access Control and Role-Based Access Control,
Attribute-Based Access Control (ABAC) is an access control paradigm that uses policy rules where the value of an attribute is attested by the user and verified in the access control processing. ABAC may fit personal data protection as it keeps separate access attributes (associated to the requestor, the resource or the context) from the policy governing the access. Existing implementation include Access Control protocols such as XACML [with its crypto variants] [ref] and assertion protocols such as SAML (which allows for assertion of Authentication, Authority and Attribute) [ref].
Attribute Based Encryption (ABE) solutions may be used for efficient access control enforcement with data stored in a not fully trusted environment, e.g., distributed systems, wherever no centralized solution (no single fully trusted server) exists. Additional advantages of ABE include:
- data consumer does not need online authentication (nor authorization) for accessing the data, as these procedures are managed directly by ABE primitives
- as there is no need for authentication, user’s identity may be protected, still preserving access control for legitimate users owing the corresponding attributes
- the data can be encrypted without knowing in advance who will perform decryption
Conceptually similar to ordinary public key encryption schemes, in ABE a content is encrypted using a public key which does not reveal any information useful to decrypt the data, e.g. the private key. Unlike ordinary public key schemes, however, the decryption key is not unique, but multiple users, having different keys, may decrypt the same message.
Furthermore, and distinguishing feature of ABE, a user can decrypt a message only if the user is provided with a set of attributes which satisfy a given policy. This feature enables a party to encrypt data without a priori knowing the identity of each individual user which shall be able to access the data. Uses could access the data as soon as they will satisfy a given policy

expressed in terms of attributes associated to them. Such policy

is expressed in a monotonic Boolean policy over attributes, it means that it could include only AND and OR statements between required attributes but no negations such as NOT: (Attribute
1
AND (Attribute
2
OR Attribute
3
)) is a valid policy for ABE while (Attribute
1
AND
NOT (Attribute
2
OR Attribute
3
)) is not available in such techniques.
The present clause explores an interesting variant of ABE, which is called Ciphertext Policy (CP-ABE). In CP-ABE the policy which needs to be satisfied by the user’s attributes is directly integrated in the encrypted data itself, merging this way confidentiality (through encryption) with access control (through policy).
In CP-ABE, at encryption time, the data owner only requires to know: i) the subset of attributes of interest, which are ordinary natural language strings, and ii) the public key of the authority which has issued such attributes.
Similarly to ordinary public keys, this information can be gathered at any time and locally cached at the provider for subsequent without requiring the authority to be online. CP-ABE does not only allow the data owner to be unaware of the set of users which will be able to access the message, but it completely decouples the encryption process from the management of the user attributes, which results to be a critical issue in an elementary public-key based scheme.
Suppose that CP-ABE encryption of a message M using policy occurs at a given time, say . Let be the resulting ciphertext – this notation highlights the fact that the policy is integrated in the encrypted data itself.
Suppose now that, at a subsequent time , a new user, say , needs to be added to the set of users allowed to access the message. Such user just need to (offline and once for all) access the attribute-issuing authority - or the set of involved authorities in a multi-authority scenario - to be provided with the attribute that permits her to decrypt the message.
ETSI

17 Draft ETSI TR 103 304 V0.0.2 (2015-05)
CP-ABE brings significant scalability advantages with respect a public-key approach, because in most CP-ABE constructions, the size of the ciphertext grows linearly with the number of attributes included in the policy, rather than with the number of users.
The CP-ABE scheme consists of four algorithms:

: Takes global parameters and attribute universe description as input and outputs the public parameters PK and a master key MK.

: Takes as input the master key MK and a set of attributes S that describe the key and outputs a private key SK.

: Takes as input the public parameters PK, a message M, and an access structure A over the universe of attributes (that represents the policy to be satisfied to access the message). The algorithm encrypts M and produce a ciphertext CT such that only a user that possesses a set of attributes that satisfies the access structure will be able to decrypt the message. The ciphertext implicitly contains A.

: Takes as input the ciphertext CT, which contains the access structure A, and a private key
SK, which is a private key for a set S of attributes. If the set S of attributes satisfies the access structure A then the algorithm will decrypt the ciphertext and return a message M.
This first CP-ABE construction [BSW07] had a significant practical limitation: attributes were issued by a single, global, authority. In order to overcome such a limitation, the cryptographic community attempted to devise multiauthority CP-ABE schemes, with the first proposal in this field being by Chase [CHA07]. However, this first multiauthority proposal, as well as the subsequent extensions, still required some form of cooperation (at least offline) among the authorities. In the real world, such form of cooperation is deemed to be unviable, as it would force all possible authorities (ranging from banks, governments, visa offices, and even individuals) to interact at least once each other, as well as re-run a cooperation protocol every time a new authority is deployed.
8.4.1 Decentralized CP-ABE
In 2011 a breakthrough paper [LW11] presented the first fully decentralized CP-ABE construction, thus broadly extending CP-ABE’s application range and making it fitting the real world needs of large scale networks and deployments. In this context, fully decentralized means that access policies can be specified over an arbitrary set of attributes issued by multiple independent and not cooperating authorities (possibly not even knowing each other’s existence).
The far from being trivial technical challenge solved in [LW11] was the construction of a scheme resistant to collusion among users: if user holds attribute issued by an authority and user holds attribute issued by a different authority which has never cooperated with , and even if the two users collude by exchanging their secrets associated to such attributes, as well as any other possible information locally held by the two users, it is not possible for each of these users to decrypt a message encrypted with the policy property is proved in [LW11].
. This
In this clause a more detailed discussion about building-blocks of a multi-authority CP-ABE-based security architecture is presented.
Attributes.
An attribute is a plain text string defined by, and associated to, an authority. For instance, an attribute can be as general as the string “visa” associated to a country-wide immigration authority and used to grant access permissions to a given country, or as specific as the string “office-mate” issued by an individual. Attributes shall not need to be globally unique (thus simplifying naming issues), but just need to be unique inside the same authority. For an example, two different countries can issue the same attribute string named “visa”, but these two attributes are different because issued by different authorities.
Attribute-issuing authorities.
An authority is any arbitrary entity (hence even including individual users) which autonomously decides to issue attributes. The set-up of an authority is thus an independent decision, and does not require any coordination or interaction with a global authority. The only requirement an authority must adhere is to use the same set of globally-defined and publicly known system parameters. An authority will be characterized by a pair of keys: a public key , and an associated private key . Each key consists of the list of public and private key pairs related to each attribute released by the corresponding authority.
ETSI

18 Draft ETSI TR 103 304 V0.0.2 (2015-05)
For each released attribute the authority computes the corresponding attribute’s public key key . More formally, the set-up of an authority is summarized by the publicly known algorithm:
and private which is independently run by each authority, and which outputs the authority’s public and private key pair:
,
Attribute-release.
In order to get an attribute from an authority, a user must have a global identity name, called UID
(user-identity), which must be a globally unique bit-string (for instance, an email address or SIP address). Attributes issued to different user-identity will not be combined in the same access control policy. In order to be granted an attribute, a user will offline submit to an authority its global identity name, and if the authority decides to issue the required attribute, the user will receive back a secret key uniquely associated to both the user as well as the attribute.
Note that this implies that different users will get different secrets for a same attribute. Formally, the attribute release procedure is an algorithm:
Where UID is the global identity name of the user, is the issued attribute name, is the Authority secret key, and is the secret key released to the user for the considered attribute. This algorithm shall be executed by the authority, and the resulting secret key shall be provided to the user via a secure channel.
The release of attributes could require a certain level of trust between the issuer (attribute-authority) and the receiver (user) that can eventually, but not necessarily, exploit a more traditional traditional PKI to support the certification of attributes and/or the individual trust relations.
Note that the system does not requires to be static but new authorities and new attributes can be placed runtime,
Data encryption and decryption.
Once authorities and attributes of the system are defined, data owner is able to run encryption (enforced by implicit access-control) of the data M. User needs to acquire public keys of attributes involved in the encryption policy in order to correctly encrypt the data. The encryption procedure uses an algorithm:
Where M is the data to be encrypted and is the policy to be applied to obtain encrypted data CT. CT will embed the access-control policy.
Once the message is encrypted, the user knows that the message will be accessed only by other users which have been issued a set of attributes by the specific authorities considered. Formally, the decryption procedure is an algorithm:
Where CT is the ciphertext and is the access-control policy to be satisfied in order to successfully decrypt the data
M.
8.4.2 Decentralized CP-ABE: Performance and overhead issues
Computational Performance. As well as for the overhead, the performance of the proposed construction is strongly influenced by the number of attributes that form the policy. Indeed, the greater the number of attributes included in the ciphertext policy, the greater the number of pairings (basic function required by such schemes) and elliptic point exponentiations required (i.e., increase of computational time) and also the larger the ciphertext overhead.
More specifically, the encryption algorithm performs 6 exponentiations and 3 multiplications for each attribute in the policy.
The decryption algorithm requires to perform 2 pairing and 1 division for each attribute (the first of two pairings is in the order of tens of microseconds so it is definitely faster than the second one thanks to the shorter size of the first point input) and a number of multiplications and exponentiations equal to the number of attributes in the policy.
ETSI

19 Draft ETSI TR 103 304 V0.0.2 (2015-05)
At the present time and using commodity hardware, an usual policy (comprising from 2 to 6 attributes), requires less that 40 ms for encryption and about 60 ms for decryption, even on a Java implementation over a low end PC. This is a promising result in terms of viability and practical acceptance.
Communication Overhead. Similarly to execution time performance, the overhead introduced by the CP-ABE encryption of a data packet follows a linear trend with respect to the number of attributes in the considered policy.
Indeed, the resulting ciphertext linearly depends on the number of attributes involved in the encryption policy and by the cyclic group , i.e. by the chosen elliptic curve, used to setup the system with a resulting ciphertext of exactly
elements of the group (N
A
is the number of attributes that define the policy). The overhead introduced is due mostly to the CP-ABE ciphertext that is linear with the number of attributes in the policy but also to the structure that defines the policy used to encrypt data, since it is included in the ciphertext. Note that the overhead is significant, and suggests that CP-ABE is (as in most applications of Public Key Encryption schemes) more effective when used in key-transport mode (i.e. if used in an hybrid encryption approach) where ABE is used to encrypt a symmetric key (let say a 128-bit AES key) which is used in turn to encrypt a large amount of data.
8.4.3 ABE policies (APTs)
ABE policies are access policy trees (APT) with a predefined set of attributes as leaf nodes. Many core authorization platforms use XACML-defined policies. A translation of XACML policies to ABE policies is needed in order to enable extended usage of attribute based encryption. There are limitations on which policies can be translated from XACML to ABE. XACML policies can express more detailed access rules and conditions than the ABE policies, which are inherently tree-based. However, some XACML policies can be mapped to ABE policies, meaning that the decisions for both the original and the mapped policies would be the same for the same requests on a particular resource. These
“safely mappable” XACML policies can be automatically translated to ABE policies with simple algorithms. The rest of the XACML policies at the present time are not automatically translable, but might be manually mapped to ABE policies by human intervention. An example of how the XACML policies can be mapped to ABE policies is depicted in
Ошибка! Источник ссылки не найден.. The subjects and attributes from a <Target> element in a XACML policy are mapped into an ABE policy. In this example the subjects are mapped into a union (OR node) and the attributes (per subject) into an intersection (AND node).
Figure 1: Mapping of XACML policy to ABE policy (APT)
ETSI

20 Draft ETSI TR 103 304 V0.0.2 (2015-05)
The ABE policies and their APTs can be optimized for encryption/decryption by normalizing their nodes. Normalization makes the usage of the ABE policies and therefore encryption and decryption processes more efficient. The reason for normalization is that the parsing of normalized access policy trees (APTs) is performed faster when the encryption and/or decryption functionalities are invoked. The normalization of a node N eliminates unnecessary gates as depicted in Ошибка! Источник ссылки не найден..
Figure 2: APT normalization example
8.4.4 Attribute Revocation
An ABE system that allows efficient attribute revocation is one of the open problems studied in the AU2EU 3 project.
Attribute revocation is about not allowing a user to use his old decryption keys associated with his lost (revoked) attributes. A trivial way of implementing revocation would be to change all the decryption keys and re-encrypt all data items. However, this solution is not practical, therefore more efficient attribute revocation solutions were proposed in the literature, where the ability to revoke attributes is mainly achieved in two ways: either by attaching expiration dates to the attributes, in such a way that decryption keys cannot be used for encryptions produced after the expiration date, or by employing a proxy that generates a decryption token after verifying that there are no revoked attributes. The first solution has the drawback that the decryption key cannot be immediately revoked when the user loses some of his attributes, but it will be expired after passing certain periods. The disadvantage of the second solution is that the proxy needs to be fully trusted so that a token for a user with revoked attributes is not generated, and second the proxy needs to perform heavy computations for the users especially if the number of access requests increases. The following subsections describe in more depth the two literature solutions and briefly introduce the solution proposed in the
AU2EU project.
8.4.4.1 Proxy Mediator Approach
The mediator approach is based on proxy re-encryption methods which use a proxy to re-encrypt the ciphertexts without revealing the plaintext. This method involves a third semi-trusted party that performs computations under the honestbut-curious trust model.
Ibraimi et. al 4 propose a proxy mediator approach where the decryption key is broken into two parts: the proxy receives one part of the decryption key and the user receives the other part. To decrypt data, the user has to first send the ciphertext to the proxy which generates a decryption token using the proxy key. The proxy holds an attribute revocation list which is updated as soon as a user loses some of his attributes. The proxy generates the token only if user attributes do not occur in the revocation list. Revocation is therefore enforced using the revocation list maintained by the proxy.
The main advantage of the proxy approach is that when an attribute is dropped from a user, the attribute will be immediately revoked form the decryption key of the user. However, this approach has inefficiency drawbacks. The proxy mediator is required to decrypt data partially upon receiving each request to generate a token. These computations impose a high load of computations which makes the proxy a bottleneck in the system when a large number of users are involved.
3
http://au2eu.eu/, AU2EU (Authentication and Authorisation for Entrusted Unions) is an EU-funded collaborative research and development project which aims at fostering the adoption of security and privacy-by-design technologies in European and global markets.
4
Luan Ibraimi, Milan Petkovic, Svetla Nikova, Pieter Hartel, and Willem Jonker. Information security applications. chapter Mediated Ciphertext-
Policy Attribute-Based Encryption and Its Application, pages 309-323. Springer-Verlag, Berlin, Heidelberg, 2009.
ETSI

21 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Xu et al.
5 perform user and attribute revocation with proxy re-encryption using a delegation key. The delegation key has two functions in this scheme: i) Re-encrypt every ciphertext requested by legitimate users and ii) can be updated to reflect the user attributes revocations. The KMA keeps part of the secret key itself and every time there is a user revocation the KMA sends a different part of the secret key (delegation key share) to the proxy storage server. When a user wants to decrypt, he makes a request to the storage server which on his side re-encrypts the data with the delegation key.
8.4.4.2 Key-Expiration Approach
The key-expiration approach uses time based decryption key, so that the key is expired after a certain period of time.
Piretti et al.
6 proposed attaching an expiration date to the attributes of the decryption key so that this key cannot be used for encryptions produced after the attached date. In their solution, when a key reaches the expiration date, the key generation authority is checking its revocation list and updates only the decryption keys of the users who do not have any revoked attributes. However, this approach requires that either the expiration date of decryption keys is the same for all the issued keys in order to enable the key authority to update the keys only at specific times, or the key generation authority updates the key frequently. This requirement makes the system either less efficient or less flexible.
To tackle this problem Boldyreva et al.
7 proposed a scheme that allows the key authority to update the decryption keys more efficiently. However, this approach is proposed for Identity Based Encryption schemes where the attribute is only the identity of the recipient.
Bethencourt et al.
8
proposed a solution that attaches expiration dates to every attribute of the decryption key and achieves enforcement by doing numerical comparisons in the policy tree. However, this scheme increases the complexity of creating the ciphertexts and the decryption key because each attribute is replaced by n attributes, where n is the number of bits used to represent the expiration date. In practice to implement a numerical comparison using policy trees one needs n more leaves (attributes) for an n -bit number. This method requires also that the user encrypting the data synchronizes the encryption time with the key generation authority so that both the encryption and decryption use the same time.
However, there are two major problems with the key-expiration and periodic key updates approach. Firstly, the attributes can only be used for new encryptions, because for older encryptions a user can still use his old decryption key. Moreover, revocation only goes into effect for encryptions produced after the new expiry date, which is usually not immediate. The complexity of the policy tree also grows unjustifiably, which can make the encryption and decryption infeasible.
8.4.4.3 Proxy-based revocation by ciphertext splitting
In this approach, used in the context of AU2EU project, the ciphertext of the ABE scheme is divided into two parts, where one part is stored on the storage cloud and the other part is stored on a mediator proxy. The proxy is a semitrusted entity that in addition to holding the corresponding part of the ciphertext has a revocation list that contains the last status of the user attributes. Each time a user wants to access the data, he needs to download the first part of the ciphertext from the storage cloud and then the second part from the proxy. Before the proxy sends the second part of the ciphertext, it is checked whether the user has any revoked attribute. In case of having any revoked attributes, the proxy will not send the second part of the ciphertext to the user, which prevents decryption of the data.
The ciphertext splitting using a proxy solution allows immediate revocation of attributes. Furthermore, it is more computation-efficient than the existing proxy mediator systems. On the other hand, in contrast to the previous proxy mediator systems, in this solution the proxy needs to store a part of each ciphertext instead of just key material,
5
Z. Xu and K. Martin, "Dynamic User Revocation and Key Refreshing for Attribute-Based Encryption in Cloud Storage," in Trust, Security and
Privacy in Computing and Communications (TrustCom), IEEE 11th International Conference, 2012, pp. 844-849.
6
M. Piretti, P. Traynor, P. McDaniel, and B. Waters. Secure attribute-based systems. Journal of Computer Security, 18(5):799-837, 2010.
7
A. Boldyreva, V. Goyal, and V. Kumar. Identity based encryption with efficient revocation. In ACM Conference on Computer and Communications
Security, pages 417-416, 2008.
8
J. Bethencourt, A. Sahai and B. Waters, "Ciphertext-policy attribute-based encryption," in Security and Privacy, IEEE Symposium on. IEEE, 2007.
ETSI

22 Draft ETSI TR 103 304 V0.0.2 (2015-05) increasing its storage costs. In this proposed system any ABE scheme from the literature can be used to cryptographically enforce access policies. For the moment this solution is still under test and review.
ETSI

23 Draft ETSI TR 103 304 V0.0.2 (2015-05)
<
>
<Text>.
Alice is a patient of a famous Hospital. Recently, the hospital has worked with a research centre to an open source software solution to keep confidential patient's medical information, yet guarantee high availability of the information to authorized medical personnel of every hospital in the Country. The solution is provided in form of an APP for wearable devices, and exploit the device's third party cloud storage functionality. Alice installs the application on her smart glasses. A key and a digital certificate is provided to her before she leaves the hospital. Her medical data is loaded in an encrypted format on her cloud storage account, to prevent access from unauthorized agents. Only Alice and authorized medical personnel will be able to access her confidential medical records, despite stored on an untrusted
Cloud storage infrastructure.
John works in the travel office of a medium size company. He is in charge of planning and arranging business trips for employees and the management board. Recently, the company has permitted employees the Bring Your Own Device policy, allowing them to bring personally owned mobile devices (laptops, tablets, and smart phones) to the workplace, and to use those devices to access privileged company information and applications. John took the chance to buy a new tablet PC and decided to use it both for work and at home.
John normally accesses the administrative App of the company to check the new travel requests. This week he has to book four flights for the CEO and some overnight stays. John is used to check flights and hotel rooms on the Internet using a popular website. When the best combination of flights and hotel is reached, John buys the package on behalf of the traveller using the company virtual credit cards.
At home, during the weekend, John is planning winter holidays for him and his family. All together start to evaluate different possibilities. Using his new tablet PC John connects to his favourite travel portal (the same he uses for his work), offering very interesting deals. When the family finds their own holydays plan, John proceeds to the purchase.
He knows very well the online procedure! The browser auto-form-filling makes the procedure even easier, if possible.
In fact, the browser saves the most frequently used data proposing the options per each field. Unfortunately this shortcut leads John to finalize his purchase without realizing that the system is using his company's credit card as payment method. As a consequence, the CEO of his company receives an automatic alert from the travel portal. On Monday
John will be informed about the raised problem.
ETSI

24 Draft ETSI TR 103 304 V0.0.2 (2015-05)
John is at home with his son, Josh. John decides to go downstairs to do some homework, leaving Josh upstairs playing videogames on his tablet PC. After a while Josh gets bored with the game, so he decides to download a new game from the APP store. He automatically connects to the store using his father's account. However, to perform a new buy the system asks for an additional password. Josh does not know the password, so he decides to download a free game. Once installed the game asks for a set of permissions. Josh agrees and the game get installed on his father's tablet PC.
Some days after. A popup appears on John's tablet PC screen, saying most of his files have been encrypted and are no more accessible. To unlock these files, John needs a special RSA key that will be sent to him after a payment, in bitcoins, to an anonymous account. What Josh installed was actually a “Ransomware”! John decides to pay. After that, a key is sent to him. Unfortunately John discovers that the key is useful to unlock only a small number of files. To unlock more he is asked to pay a second ransom...
Profiling users is a practice which has its origins in managing fraud and access control in financial and ICT systems, and in law enforcement and national security communities attempts to deal with serious crime and terrorism. It has also been used by the marketing sector and in consumer reporting services for targeted advertisements. Increasingly, it is used to provide a broad array of free services to users to enable “free at point of delivery” services with the necessary revenue generation achieved through the sale of data analysis of user behavior and data. Most service models – especially free ones – are non-negotiable. When users subscribe to new services for free by installing applications, service providers collect and store that data in their service infrastructure - obtaining valuable information from both data and metadata. Such data analysis may disclose sensitive personal data. A significant data-ecosystem may exist between the user and the service provider.
Jane, John's wife, works as a nurse in a famous hospital of her city. Everyday she is used to drive from home to the workplace. Recently she installed a free messaging application to get in touch with her family members, her friends and her colleagues. The application asked her a number of permissions including access to her GPS position and her contact list, but she wasn’t able to understand the terms of use and thus blindly accepted all conditions. Jane's colleagues, friends and family members were made aware of the APP as well, because Jane consented a feature of the APP telling her contacts she has installed and was actually using the APP. Jane discovered that her colleagues joined a “chat group” to discuss work issues, problems, or simply to enjoy the group chat. As she is very social she decided to join the group.
One day she even posted to the group a picture of herself with some colleagues at work.
Some weeks after, the APP started suggesting new contacts she might know. Jane was surprised, as actually she knew some of those people: they were coworkers and people living near her home. In addition, the APP started displaying advertisements of medical products; some products were of few interest for her, but others were interesting. As Jane started watching some suggested commercials, she discovered products were from a competitors of the manufacture her hospital is used to buy and were offered with a larger discount.
Months later she was even more surprised to find on the web an online banner showing a group of nurses promoting some medical products. She found the picture was vaguely familiar to her.
There are positive aspects to cloud or remote storage – data is no longer dependent on the device used to create it and manage it. However, cloud computing storage at large date centres may increase the risk of temporary inaccessibility or even large losses of personal data. In 2011 a large hosting company was offline for due to power lost after a fire broke out in one of their UPS rooms. For a whole morning their clients and customers of their clients were unable to use services there hosted.
ETSI

25 Draft ETSI TR 103 304 V0.0.2 (2015-05)
<
>
The following non fictitious use cases are part of AU2EU project’s pilots
9
.
Biosecurity is critical for Australia's natural environment, due to the country's unique geographic location. To protect
Australia’s natural environment from exotic diseases, the Australian Federal and State governments, key research and industry groups have established the Consultative Committee on Emergency Animal Disease (CCEAD) to organize the collaborative responses when Emergency Animal Diseases (EADs) incidents occur. These collaborative responses require many interactions among the involved organizations, with a considerable amount of sensitive information being shared. The system works using the CSIRO Collaboration Platform (CCP) which facilitates video conferences and
shared documents amongst participants as depicted in Figure 3. AHA (Animal Health Australia), AAHL (Australian
Animal Health Laboratory) and DAFF (Department of Agriculture Fisheries and Forestry) are Australian organizations which can take part in biosecurity incidents.
Figure 3: Example of an incident meeting
10
EAD responses involve discussions using a lot of sensitive biological data. Data is stored in an encrypted form and is sent, still encrypted, to mobile users. Attribute Based Encryption (ABE) allows users with attributes matching predetermined policies to decrypt and access this data.
The encryption is made before knowing the actual identities of users who will access the data; in comparison with other encryption methods, therefore, data is efficiently encrypted only once and does not need to be (re-)encrypted whenever new users join the system.
A main alternative would be using a different ephemeral key for each piece of data and storing these keys on an online key server. In comparison with this approach the advantage of ABE is that there is no longer any need for an online component.
The data is encrypted by the producer (e.g. CCP AHA) using an ABE policy. Later these resources are decrypted by data consumers. Data consumers include users within the CCPs connected to the incident’s shared workspace, and mobile field users. The first connect to the workspace using the CSIRO Collaboration Platform (CCP), while the latter use mobile devices with reduced screen size.
9
J. Zic, B. Lange, T. Ignatenko, D. Pletea and P. Koster, “AU2EU, D1.1.1 - Detailed Description of Use Cases,” http://au2eu.eu/, 2014.
10
J. Zic, D. Pletea, S. Thaler, and D. Gessner. AU2EU, D3.4.1 - Adjusted authorisation platform for the pilots. http://au2eu.eu/, 2015.
ETSI

26 Draft ETSI TR 103 304 V0.0.2 (2015-05)
The flow of a biosecurity incident meeting contains the next actions:
 a new meeting is started and the participants connect to the incident’s shared workspace

CCP users retrieve documents from the encrypted storage and decrypt using ABE decryption.

CCP users and field users are also able to upload data in the Encrypted Storage. The uploaded documents are
ABE encrypted using one of the existent ABE policies. The ABE policies are defined by the data producer
(e.g. CCP AHA).
Figure 4: ABE extension for the Biosecurity use case
For the field users, access to the encrypted storage may be based on (possibly anonymous) credentials. The only requirement on accessing the store is that appropriate credential is presented, without necessarily revealing the user’s identity.
In the eHealth Efficient Care Coordination there are three main actors: Patient, Care Coordinator and Care Giver.
Included in the obligations of a Care Coordinator is the provisioning of third Party home and health care services (e.g. nursing, first aid, medical services) in response to a help request, e.g. in an emergency situation: if the Patient has actively pushed an emergency button, or if an alarm has been triggered by the system. It is in the interest of the Care
Coordinator that these individualized services are provided in a fast, reliable and efficient manner to the satisfaction of the Customer.
Once the Care Coordinator has selected a third Party Home/Health-Care Service Provider, this Service Provider dispatches a mobile Care Giver based on availability and circumstances.
ETSI

27 Draft ETSI TR 103 304 V0.0.2 (2015-05)
Figure 5: Efficient Care Coordination use case
The goal of this use case is to provide a Care Giver with the necessary and relevant Customer data on a mobile device.
This is necessary in order to facilitate that the Care Giver is responding efficiently to a Patient’s help request, i.e. travelling to the Patient’s residence and providing the best treatment in a given situation. It is also needed to ensure a timely response for the Patient in potentially critical situations and also to enhance the staff and Patient safety and
service levels by exchange of information vital for the quality of the service. This use case is depicted in Figure 5.
Using ABE, access to encrypted data can be enforced even when the hosting servers are not fully trusted. This requires that all the data is ABE encrypted before being shared with other parties.
When an emergency call is received from the patient:
 the Care Giver is sent to the field
 when the Care Giver reaches the patient a data request is sent to the Care Coordinator
 the Care Coordinator retrieves the requested data from the patients’ records
 the Care Coordinator encrypts the requested data using an appropriate ABE policy. The Care Coordinator may use XACML policies translated into ABE
 the ciphertext is cached to ensure reuse in a subsequent request, if the data and the policy have not changed
 the ABE-encrypted data is sent to the Care Giver

The Care Giver decrypts the data using the ABE secret-key
ETSI

28 Draft ETSI TR 103 304 V0.0.2 (2015-05)
V0.0.2
V0.0.0
V0.0.1
February 2015
First draft by Giovanni Bartolomeo (CNIT)
Email: Giovanni.bartolomeo@uniroma2.it
March 2015
May 2015
Clean-up done by editHelp!
E-mail: mailto:edithelp@etsi.org
Major revision by Giovanni Bartolomeo (CNIT)
Email: Giovanni.bartolomeo@uniroma2.it
June 2015
August 2015
Included contribution by Alberto Caponi (CNIT) on CP-ABE
Sections: “ABE policies (APTs)” and “ABE Use Cases”, AU2EU project contribution (Daniel Pletea, daniel.pletea@philips.com)
September 2015 Section: “Attribute Revocation” (Daniel Pletea, daniel.pletea@philips.com)
October 2015 Comment addressed, added section on ISO 29100, editorial changes (Alberto
Caponi, Giovanni Bartolomeo CNIT)
ETSI