Attribute-Based Encryption in Systems With Resource Constrained Devices in An Information Centric Networking Context

UPTEC F 16037
Examensarbete 30 hp
Juni 2016
Attribute-Based Encryption in
Systems with Resource Constrained
Devices in an Information Centric
Networking Context
Joakim Borgh
Abstract
Attribute-Based Encryption in Systems with Resource
Constrained Devices in an Information Centric
Networking Context
Joakim Borgh
Teknisk- naturvetenskaplig fakultet

UTH-enheten An extensive analysis of attribute-based encryption (ABE) in systems with resource
constrained devices is performed. Two system solutions of how ABE can be
Besöksadress: performed in such systems are proposed, one where the ABE operations are
Ångströmlaboratoriet
Lägerhyddsvägen 1 performed at the resource constrained devices and one where ABE is performed at a
Hus 4, Plan 0 powerful server. The system solutions are discussed with three different ABE
schemes. Two of the schemes are the traditional key policy ABE (KP-ABE) and
Postadress: ciphertext policy ABE (CP-ABE). The third scheme is using KP-ABE to simulate
Box 536
751 21 Uppsala CP-ABE, in an attempt to benefit from KP-ABE being computationally cheaper than
CP-ABE while maintaining the intuitive way of using CP-ABE.
Telefon:
018 – 471 30 03 ABE is a computationally expensive encryption method which might not be feasible to
Telefax: perform at the resource constrained sensors, depending on the hardware.
018 – 471 30 00
An implementation of a CP-ABE scheme with a 128-bit security level was written and
Hemsida: used to evaluate the feasibility of ABE on a sensor equipped with an ARM Cortex-M3
http://www.teknat.uu.se/student
processor having 32 kB RAM and 256 kB flash. It is possible to perform CP-ABE on
the sensor used in this project. The limiting factor of feasibility of ABE on the sensor
is the RAM size. In this case policy sizes up to 12 attributes can be performed on the
sensor.
The results give an idea of the feasibility of encryption with ABE on sensors. In
addition to the results several ways of improving performance of ABE on the sensor
are discussed.
Handledare: Börje Ohlman

Ämnesgranskare: Christian Rohner
Examinator: Tomas Nyberg
ISSN: 1401-5757, UPTEC F16 037
Populärvetenskaplig sammanfattning
”Smart city” eller smart stad är en term som åsyftar en framtida stadsvision där information- och
kommunikationsteknologi (ICT) är en väsentlig del. I en smart stad kan ICT användas för att
mäta olika aspekter i staden, öka effektiviteten av tjänster som staden erbjuder samt förbättra
samverkan mellan medborgare och stat. Datan som samlas in under mätningar kan ge informa-
tion om vilket tillstånd ett visst område befinner sig i och hur detta påverkar medborgarnas hälsa.
Dessa mätningar utförs av små sensorer som kan integreras i byggnader, bilar eller andra object.
Dessa sensorer är en del av det så kallade Internet of Things (IoT). Enheter i IoT är vanligtvis
begränsade i termer of beräkningsförmåga av praktiska skäl som att minska priset på enheten eller
för att minska energiförbrukningen för att förlänga batteritiden.
Datan som samlas in av sensorerna kan göras tillgänglig för allmänheten genom att ladda upp
den till ett nätverk. För att delningen över nätverket ska vara effektiv kan Information-Centric
Networking (ICN) användas. ICN är en alternativ nätverksarkitektur där datan i nätverket är
namngiven istället för ändpunkterna som i dagens internet. I ICN kan data sparas i mellanlig-
gande noder, t.ex. routrar. Datan som efterfrågas kan hämtas oavsett var i nätverket den är
lagrad och därför kan flaskhalsar i nätverket undvikas. Dessutom genom att namnge datan blir
konsumenterna i nätverket ovetande om varifrån datan hämtas vilket kan vara till fördel i nätverk
där alla noder inte alltid är tillgängliga i nätverket.
En del av datan som samlas in kan eventuellt vara privat och måste därför ha någon sorts skydd
så att bara behöriga personer har tillgång till datan. Ett vanligt sätt att förhindra obehöriga från
att ta del av datan är att kryptera den. Traditionella krypteringsmetoder krypterar datan till
en specifik person och måste därför krypteras en gång per behörig person och skapar således en
ny fil per person. Detta är problematiskt då dessa filer inte kan nyttjas om de sparas i routrar
i nätverket, eftersom enbart en specifik person kan öppna dem. En lovande lösning till detta är
Attribute-Based Encryption (ABE).
ABE tillåter den som krypterar att kryptera datan utan att veta identiteten på alla mottagare.
Istället använder den som krypterar beskrivande attribut för att specificera vem som är behörig
att avkryptera datan. Kryptering med ABE har egenskapen att datan bara behöver krypteras en
gång oavsett antalet mottagare, därför kan denna krypterade datan också sparas i routrar. Detta
gör ABE till en lämplig krypteringstyp för ICN. Nackdelen med ABE är att det är en kostsam
krypteringsmetod i termer av beräkningar. Denna egenskapen kan vara problematisk i ett system
där sensorer med begränsad beräkningsförmåga måste utföra krypteringen.
I detta project föreslås två system lösningar till hur ABE kan användas i system som innehåller
enheter med begränsad beräkningsförmåga. Lösningarna diskuteras baserat på experimentella
resultat av ABE kryptering på en sensor. Den mest lämpliga lösningen beror på hur begränsade
sensorerna är i beräkningsförmåga, antalet beskrivande attribut som används vid kryptering samt
eventuella tidskrav som finns i tillämpningsområdet.
iii
Contents
1 Introduction 1
1.1 Project description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Background 3
2.1 Information Centric Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Content Centric Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Security in ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Symmetric key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Public key cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.3 Security levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Mathematical tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Cyclic group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2 Finite fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.3 Elliptic curve cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.4 Multiplicative and additive notation . . . . . . . . . . . . . . . . . . . . . . 7
2.4.5 Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.6 Lagrange polynomial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Shamir’s Secret Sharing Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Security on sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Attribute-based encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7.1 General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7.2 Multi-authority ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.3 Key revocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.4 Computational requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.5 ABE on resource constrained devices . . . . . . . . . . . . . . . . . . . . . . 12
2.7.6 The low-level operations of ABE . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Software 15
3.1 QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Valgrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Relic-toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 The Functional Encryption Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Hardware 16
4.1 Laptop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Schemes 17
5.1 Scheme discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Simulated CP-ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 System 21
6.1 System overview and scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1 Proposal I - Authority ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.2 Proposal II - Sensor ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7 Implementation 23
8 Results 25
8.1 Sensor performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iv
9 Discussion 28
9.1 System proposals and schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1.1 Simple CP-ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10 Conclusions 31
11 Acknowledgements 32
v
1 Introduction
The term smart city is often used to describe an urban development vision where information and
communication technology (ICT) is a vital part. The ICT can be used to monitor certain aspects
of the city, increase efficiency of services provided by the city and improve interactivity between
citizens and government. The data collected from monitoring can be used to draw conclusions
about the state of the surroundings and how it affects the health of the citizens. The monitoring
is performed by small sensors which can be integrated into buildings, cars or other objects. These
sensors are part of the so called Internet of Things (IoT). Devices in the IoT are usually resource
constrained for practical reasons such as reducing the prize of the device and limiting energy con-
sumption to increase battery lifetime.
The data collected by the sensors is made available by uploading it to a network. To have an
efficient sharing across the network Information-Centric Networking (ICN) can be used. ICN is an
alternative network architecture where the data is named rather than the end-points. ICN allows
data to be cached at intermediate nodes, such as routers. The data requested can be obtained
regardless of where in the network it is stored and therefore congestion and bottlenecks can be
avoided. Additionally, by naming content the consumers in the network become source agnostic
which is beneficial in networks where not all nodes are in the network at all times.
Some of the data gathered might be sensitive and should therefore have some protection such
that it can not be accessed by unauthorized persons. A classical way enforcing access control is
by encrypting the data. Traditional encryption methods encrypt the data for a specific user and
must therefore be encrypted once for every user it is intended for, i.e. creating a separate object
per user. This conflicts with the main property of ICN as this encrypted data object can only be
accessed by one person and thus this object does not benefit from being cached in the network.
A promising solution to this is attribute-based encryption (ABE).
ABE allows the encryptor to encrypt the data without knowing the identities of all recipients.
Instead the encryptor uses descriptive attributes to specify who can access the data. With ABE
the data only needs to be encrypted once regardless of how many recipients there are, thus the
encrypted data can be cached and therefore ABE is suitable for ICN. The cost of this expressive-
ness is computational efficiency. The ABE operations are expensive and might conflict with the
resource constrained sensors.
In this project two ways of employing ABE in systems with resource constrained devices are pre-
sented. The solutions are discussed based on experimental results of the encryption algorithm
of ABE on a resource constrained sensor. The most suitable solution is determined by the com-
putational power of the sensor, the maximum policy length and the time requirements of the
application. In addition three different ABE schemes are discussed for these two system solutions.
1.1 Project description

There is an ongoing project named ”Green IoT” which is working towards making Uppsala a smart
city. This project is a collaboration between different universities, companies and other research
institutions. The collaborators are Uppsala University, KTH, SICS, Uppsala Kommun, Ericsson,
IBM, SenseAir AB, Upwis AB and 4Dialog AB. In this project sensors are being deployed in the
city to gather data about air pollution. One part of this project is to evaluate the performance
of information-centric networking (ICN) in this context and it is within this part that this thesis
is performed [5]. A conceptual picture of the setup of the system can be seen in Figure 1, this
is a general setup and describes how the data is transmitted from the sensors to the user in the
network.
1
Figure 1: A conceptual image of the Green IoT system.
Suppose that the data collected by the sensors is sensitive and the gateway is not trusted. The
data should therefore be encrypted and this encryption must take place at the sensors as the
gateway is not trusted. In an ICN context a promising encryption type is attribute-based encryp-
tion (ABE). However, ABE is significantly more costly in terms of computations than traditional
encryption methods and the sensors in the system are resource-constrained devices.
The goal of this project is to investigate how ABE can be used in this system with resource-
constrained devices under the assumption that the gateway is not a trusted entity. In other
words, the intention is to answer the question: ”Is it possible to perform ABE at the sensors and
to what extent, or must other solutions be considered and if so, what are these other solutions?”
2
2 Background
2.1 Information Centric Networking
When the current Internet architecture was created it was designed with communication between
two computers in mind. Lately the way we use the Internet has shifted from communication to-
wards content distribution such as video, photo and document sharing. Therefore the architecture
of Internet can be redesigned to improve content-dissemination to better suit the way Internet is
used today. An attempt of doing so is called Information Centric Networking (ICN). In ICN the
content is addressed and named, rather than the end-points. This allows content to be retrieved
regardless of where in the network it may be stored and can therefore reduce congestion and bot-
tlenecks in the network. There are some different examples of ICN architectures, among the most
popular are Named Data Networking (NDN) and Content-Centric Networking (CCN) [25] .
There are three key changes required to shift the model from communication towards distribution,
these are:
1. Naming: Name and address the content rather than the end-points. This allows content to
be retrieved regardless of where in the network it is stored.
2. Memory: In a communication network the memory is invisible. In a distribution network
the memory in the network (i.e. routers cache) is utilized to possibly cache content which is
requested often.
3. Security: In a communication network the security is based upon establishing a safe channel
between the end-points. In a distribution network the security is based on securing the
content itself as it is disseminated within the network and can be obtained from anywhere
within the network by knowing the contents name.
2.1.1 Content Centric Networking

Content-centric networking is an example of an ICN architecture created by Palo Alto Research
Center (PARC).
Communication in CCN uses two packet types: interest packets and content packets. A consumer
asks for content by sending an interest packet. Any CCN node which possess the content re-
quested in the interest packet will respond with a content packet with the requested content. A
CCN node may forward an interest packet if it can not satisfy the request itself. The CCN node
has forwarding tables that determine which direction to send the interest packet. Content packets
contain, in addition to the requested data, the full name, a signature for the packet, information
that identifies the signer and support details. This additional information is useful to ensure the
integrity of the content. CCN employs flow balance meaning that an interest packet is always
answered by only one content packet and no content packet is sent without a request.
Further information and more detailed description of CCN can be found in [25].
2.1.2 Security in ICN

Encryption is a tool to secure the content itself, which is needed in ICN. Traditional encryption
methods are problematic in ICN as they encrypt the data for a specific user, thus data encrypted
this way does not benefit from caching as it is a separate object for every user. In ICN attribute-
based encryption (ABE) is a promising encryption method as the data is described by attributes
and a single object is needed to encrypt it to any amount of users. Therefore the encrypted data
can also be cached, thus the efficient content dissemination can be maintained for encrypted data
traffic too.
Other efforts of enforcing access control in ICN have been made, for example in [19] an encryption-
based access control framework is presented for ICN. It is particularly useful for large content or
3
content which consist of many content objects such as a video. Another idea to ensure object
security is called Interest Based Access Control (IBAC) and is presented in [15]. IBAC works
with an idea that only authorized consumers should be able to issue proper interests for protected
content objects. This is realized through obfuscating the names of protected content files. This
method is susceptible to attacks from eavesdroppers and denial of service-attacks. The method is
not mutually exclusive with encryption and could perhaps be used together with encryption for
files that contain particularly sensitive information.
2.2 Encryption
There are three commonly used keywords in information security, these are:
1. Confidentiality - The assurance that only authorized entities can get access to the content
of the file.
2. Integrity - The assurance that the content of a file has not been tampered with or altered.
3. Authenticity - The assurance that one entity is the entity he/she/it claims to be.
Encryption is a tool to encode to the contents of a file/message to provide confidentiality and only
allow users with a correct key to decode it. This is done by encoding the message (also called
plaintext) into a ciphertext. The ciphertext is a non-trivial obfuscation of the plaintext. In order
to restore the plaintext, the ciphertext has to be decoded with the proper key which should only
be known to authorized recipients. Encryption does not guarantee that the message will not be
intercepted by an adversary, it just obstructs the adversary from seeing the real message. It is
possible for an adversary to decrypt a message without possessing the key for decryption, however,
for an elaborate encryption scheme it requires tremendous amounts of computational resources
and large amounts of time. There are two main groups of encryption: symmetric key encryption
and public key encryption.
2.2.1 Symmetric key encryption

Symmetric key encryption is an encryption scheme where the same key is used for encryption and
decryption. This requires both parties to have exchanged a key, which should be used during the
communication, prior to the secure communication. There are different ways to securely exchange
a shared key for the parties and one of these are public key encryption.
One of the most common symmetric encryption algorithms is Advanced Encryption Standard
(AES).
2.2.2 Public key cryptography

In public key encryption (or asymmetric encryption) every user in the system generates a key
pair, a public key and a private key. A user’s public key is public and anyone in the system can
access it and a user’s private key should be kept private. The asymmetric encryption algorithm
has the property that if encrypted with a particular public key it can only be decrypted by the
corresponding private key. Suppose that a user Alice wants to encrypt a message to another user
Bob in the system. If Alice encrypts her message with Bob’s public key and then sends the message
to Bob, Bob can then decrypt the message using his private key. This type of encryption requires
no pre-determined shared secret to begin secure communication as only the intended recipient
can decrypt the message. The public and private key of a user is related by some cryptographic
algorithm which is based on some mathematical problem which currently has no efficient solution,
e.g. integer factorization and discrete logarithm. It is computationally easy to generate a public
and private key pair for a user. The security of the encryption lies in the difficulty of computing
the private key from the corresponding public key.
The public encryption algorithms known today require significantly more computational effort
than the symmetric key encryption algorithms do. Therefore it is common to initialize a session
4
with a public key message to share a symmetric key and then use this symmetric key the rest of
the session.
A benefit of public-key encryption is that if one of the parties, say Bob, is reckless with his private
key then only messages intended for Bob are compromised. Thus Alice is not penalized by Bob’s
recklessness and can securely communicate with any other party but Bob.
One of the most widely used public-key encryption methods is called RSA, named after the
surnames (Rivest, Shamir and Adleman) of the creators of the algorithm.
2.2.3 Security levels

In cryptography the security level of a scheme is often measured in bits, e.g. 80 bit security. This
measure origins from the key length of a symmetric key. If there is no structural weakness of the
symmetrical encryption algorithm an attacker’s only option is to do a brute force attack. This
means that the attacker makes an exhaustive search by trying all possible keys in the entire key
space. A key of length of 80 bits means that the key space consists of 280 different keys. By
increasing the key length the number of possible keys grows exponentially and the security level
is increased as well.
In asymmetric encryption the key length does not directly correspond to the security level. In-
stead the security of asymmetric encryption is dependent on the intractability of the underlying
mathematical problems such as integer factorization. However, the National Institute of Stan-
dards and Technology (NIST) and other institutes have guidelines for translating the key size of
asymmetric encryption algorithms to a security level in terms of symmetric key length. For ex-
ample NIST guidelines state that for 80 bit security RSA a prime modulus of 1024 bits is needed.
More information about key length recommendations can be found in [2].
2.3 Serialization
Serialization is the process of writing a data structure to a format, a sequence of bytes, which can
be stored in a file, a memory buffer or transferred over a network. The reconstruction from this
format back to the data structure is called deserialization. The C programming language has no
built-in serialization function and therefore one has to be written manually if needed. A sequence
of bytes in C is represented by a byte array, i.e. an array of uint8 t. In Listing 1 a simple
example of serialization and deserialization of an int in C can be seen. Serialization is hardware
dependent as the endianness of the architecture might differ.
5
Listing 1: A simple example of serialization and deserialization of an integer.
/∗ S e r i a l i z a t i o n o f an i n t
b u f f e r , b y t e a r r a y where t h e s e r i a l i z e d i n t w i l l be s t o r e d
val , int to s e r i a l i z e ∗/
void i n t t o b y t e s ( u i n t 8 t ∗ b u f f e r , int v a l ) {
f o r ( int i = 0 ; i < s i z e o f ( int ) ; ++i ) {
b u f f e r [ i ] = v a l >> 8∗ i ;
}
}
/∗ D e s e r i a l i z a t i o n o f an i n t
∗ val , p o i n t e r t o i n t where d e s e r i a l i z e d i n t w i l l be s t o r e d
∗ buffer , byte array containing s e r i a l i z e d i n t ∗/
void b y t e s t o i n t ( int ∗ val , u i n t 8 t ∗ b u f f e r ) {
int i , tmp ;
∗ val = 0;
f o r ( i = 0 ; i < s i z e o f ( int ) ; ++i ) {
tmp = b u f f e r [ i ] ;
∗ v a l += tmp << 8∗ i ;
}
}
2.4 Mathematical tools

In this section some mathematical tools needed for the understanding of the implementation and
the scheme are introduced. The tools are described briefly and at a level sufficient for understand-
ing of this project, for more information about a particular mathematical tool see the references
of that section.
2.4.1 Cyclic group

A group in mathematics is a set of elements which are associated to an operation that combines
any two elements in the group to form a third element in the group. In order for the set and the
operation · to qualify as a group G they must satisfy the four group axioms:
1. Closure: if a, b ∈ G, then a · b ∈ G
2. Associativity: a · (b · c) = (a · b) · c
3. Indentity element: There exists an identity element e such that a · e = a
4. Inverse: Every element has an inverse, that is: for every a there exists b such that a · b = e
In a cyclic group there exist a single element g from which every other element in the set can be
obtained by repeatedly applying the group operation to g. The element g is called the generator
of the group [18].
An example of a cyclic group is the set {0, 1, 2, 3} with addition modulo 4. In this case the element
1 is a generator of the group, as every element in the group can be obtained by adding 1 to itself.
2.4.2 Finite fields

A finite field is a mathematical group with a finite number of elements. An example of a finite
field is all the integers modulo a number p, this finite field is denoted Zp .
6
2.4.3 Elliptic curve cryptography
Elliptic curve cryptography (ECC) is a type of public key encryption based on elliptic curve groups
over finite fields. An elliptic curve is the set of points described by the equation:
y 2 = x3 + ax + b, (1)
where a and b are parameters that determine the shape of the curve. An elliptic curve group G
consists of the elliptic curve and a group operation called addition, denoted by ’+’. Furthermore
a point at infinity is needed, denoted 0 which serves as the identity element.
In addition to the four group axioms the addition operation of elliptic curve groups has the prop-
erty of being commutative, i.e. if P, Q ∈ G then P + Q = Q + P .
For the purposes of this project a high level understanding of the elliptic curve group is sufficient,
for more detailed information see [29].
2.4.4 Multiplicative and additive notation

In group theory there are two notations which are commonly used, multiplicative and additive
notation. In elliptic curve groups the additive notation is normally used. However, when describing
general schemes which may use different groups some authors use multiplicative notation. Table
1 shows how the operations of the different notations correspond to each other.
Table 1: Shows how the different notations correspond to each other, P, Q are elements in the
group and a is a scalar.
Multiplicative notation Additive notation
PQ P +Q
Pa aP
1 (identity element) 0 (referred to as point at infinity)
2.4.5 Pairing
In a multiplicative notation the pairing operation can be written as:
e : G1 × G2 → GT , (2)
where G1 , G2 and GT are three multiplicative cyclic groups of prime order p and e is a bilinear
map. Let g1 be a generator of G1 and g2 be a generator of G2 . The bilinear map e has the
following properties:
1. Bilinearity: for all u ∈ G1 and all v ∈ G2 and a, b ∈ Zp , we have: e(ua , v b ) = e(u, v)ab .
2. Non-degeneracy: e(g1 , g2 ) 6= 1.
Also notice that the map e is symmetric because e(g1a , g2b ) = e(g1 , g2 )ab = e(g1b , g2a ) [33].
If G1 = G2 the pairing is called symmetric otherwise it is an asymmetric pairing i.e. when

G1 6= G2 .
2.4.6 Lagrange polynomial

In polynomial interpolation, where a set of points {(x1 , y1 ), . . . , (xn , yn )} is given and one finds a
polynomial which goes through these points, the Lagrange polynomial is the unique polynomial
of least degree that assumes these points. The Lagrange polynomial L(x) is computed from
n
X
L(x) = yi ì (x), (3)
i=1
7
where ì is the Lagrange basis polynomials which in turn are computed by
n
Y x − xj
ì (x) = . (4)
xi − xj
i6=j,j=1
2.5 Shamir’s Secret Sharing Scheme

The basic idea of Shamir’s secret sharing is that it requires 2 points to uniquely define a line, 3
points to uniquely define a parabola and more generally k points uniquely define a (k − 1) degree
polynomial. This idea can be used to construct a k of n threshold secret, i.e. the secret is split
into n parts and it requires k parts to fully reconstruct the secret. This secret sharing has the
property that someone with knowledge of (k − 1) or fewer parts can not determine the secret, but
anyone with k or more parts can easily recover the secret [27].
Suppose that there is a secret s which is to be shared in a k of n threshold fashion. The first step
is to generate a (k − 1) degree polynomial
P (x) = a0 + a1 x + · · · + ak−1 xk−1 (5)
by setting a0 = s and randomizing coefficients (a1 , a2 , . . . , ak−1 ). Even though s could be set
as any coefficient it is common practice to choose P (0) = s. Then n points on this curve are
evaluated, creating the shares (xi , P (xi )) for i = 1, . . . , n.
Reconstructing the secret s given any k shares: {(x1 , P (x1 )), . . . , (xk , P (xk ))} is done by com-
puting the Lagrange polynomial evaluated at zero. This in turn is done by first computing the
Lagrange basis polynomials evaluated at zero:
Y xj
ì (0) = , (6)
xj − xi
i6=j
then the secret can be reconstructed by

k
X
s = P (0) = P (xi )ì (0). (7)
i=1
2.6 Security on sensors

The popularity of sensor networks is increasing due to the versatility and the low cost of the
networks which yield cheap solutions to many applications. The increase of interest in sensor net-
works also directly increases the demand of proper security solutions in sensor networks. Sensor
networks are constrained in terms of resources and computing power and they are employed in
a different manner than ordinary computer networks. Therefore they face different security chal-
lenges than ordinary computer networks, thus the ordinary computer networks security solutions
may not be appropriate in a sensor network due to the constrained nature of the network.
The major concerns that stems from the hardware constraints of the sensors are the limitation in
memory, storage space and power. The limited memory and storage space forces the code related
to security to be small in size. Regarding the power consumption one has to take into account
the extra processing work inferred by the security operations (encryption, decryption, signing and
verification) and the additional energy required to transmit the message overhead introduced by
the security algorithms [32].
Symmetric key encryption is typically no problem to perform at the resource constrained sensors.
In fact, it is not uncommon that sensors have built-in hardware support for symmetric encryption,
as it is a vital part of secure communication. However, public key encryption is more expensive
and since sensors generally don’t have hardware support for public key encryption it requires a
8
software implementation. Such an implementation consumes several kB of the constrained de-
vice’s memory space because it requires implementations of multi-precision integers and modular
arithmetic.
There have been several research attempts that try to circumvent the need of public key encryp-
tion on sensors. However, these attempts do not yield the same degree of security or functionality.
Thus, actual public key encryption is preferred on the sensors [24].
Elliptic curve cryptography (ECC) tends to be the most popular choice for public key encryption
at sensors due to the small key sizes and relatively fast computations. For example, to achieve
a 80-bit security level a 160-bit curve in ECC is needed while RSA needs a 1024-bit key. In
[24] ECC operations are implemented for sensors and different optimization techniques to reduce
RAM usage, ROM usage and time for the operations are shown. They manage to run the ECC
operations on sensors with only 10 kB of RAM. These results suggest that public key encryption
at sensors is feasible and this is likely to become even better with time as more powerful sensors
will be available for cheaper prices.
Another issue with public key encryption is that in order to avoid man-in-the-middle attacks
certificates have to be issued (called a public key infrastructure). These certificates have to be
stored, exchanged and verified which infers extra storage, communication and computations for
the sensors. This has prompted researchers to explore different ways of key exchange among these
identity-based encryption (which is the encryption type that attribute-based encryption sprung
from) can be found. In identity-based encryption pairings have to be computed which is also a
component of attribute-based encryption. These pairings are regarded computationally expensive,
even so in [26] a pairing is computed on a 8-bit processor with only 4 kB of RAM.
2.7 Attribute-based encryption

2.7.1 General information
Attribute-based encryption (ABE) is a form of public key encryption where data is described with
attributes as meta-data. The attributes decide how the data is encrypted. This way data can be
made accessible only to entities that have the corresponding keys, which also consists of attributes.
Unlike traditional public-key encryption methods ABE allows the encryption to be expressive and
not only for a particular user. There are two types of ABE: Key-Policy ABE (KP-ABE) and
Ciphertext-Policy ABE (CP-ABE). In KP-ABE the access policy is embedded in a user’s private
key and the attributes are used to describe the ciphertext. In CP-ABE the policy is embedded in
the ciphertext and each user’s private key is a collection of attributes. In both types of ABE a
successful decryption can happen if and only if the attributes of the ciphertext/user’s key satisfies
the access policy in user’s key/ciphertext. An example of a CP-ABE could be that a physician
encrypts a patient’s health record under the access policy: (“Physician” AND “Hospital A”) OR (
“Insurance company A” AND “Health Insurance Department”). A user that wants to decrypt
this file must then possess the attributes of being a physician and be affiliated with a certain
hospital or that the user has the attributes of working at the health insurance department of a
particular insurance company. The person performing the encryption does not need to know the
exact identities of the all authorized recipients instead it suffices with specifying these descriptive
attributes.
The descriptive access policy which is specified is turned into an access tree before it is embedded
in the user’s key/ciphertext. It is turned into an access tree to be able to enforce the policy via
secret sharing in a structured way. In Figure 2 the access tree corresponding to the descriptive
access policy specified in the above example is shown.
9
Figure 2: The access tree generated from the descriptive access policy: (“Physician” AND
“Hospital A”) OR ( “Insurance company A” AND “Health Insurance Department”).
A typical ABE system consists of four algorithms: setup, key-generation, encrypt and decrypt.
Below a description of the algorithms is shown for CP-ABE. The same algorithms are present in
a KP-ABE system but one associates the ciphertext CT with a set of attributes S instead of an
access policy A and embeds an access policy in the user’s private key instead of a set of attributes S.
Algorithm Function
setup No input except an implicit security parameter. This al-
gorithm is called only upon initialization of the system to
generate public key P K and master-key M SK in the sys-
tem.
encrypt Input: a message M , the public key P K and an access
policy A for which the message should be encrypted. It
outputs a ciphertext CT which is the encrypted message
with the access policy A embedded.
key-generation Input: the master-key M SK and a set of attribute S as
input. It outputs the private-key SK corresponding to the
attributes in S.
decrypt Input: a ciphertext CT , the public key P K and SK as in-
put. SK is the private key of the user trying to decrypt. If
the decryption is successful (i.e SK contains the attributes
satisfying access policy A) it will output the original mes-
sage M .
The low-level inner workings of an ABE system is based on elliptic curve cryptography and is
explained in more detail in section 2.7.6.
An essential property of a well-designed ABE system is collusion resistance. This means that if
users combine their private keys they should not be able to decrypt files which they could not de-
crypt individually. Relating back to the former example of the encrypted patient’s health record,
if there are two users A, with the attributes (“Hospital B”, “physician”), and B, with the at-
tributes (“Hospital A”, “Nurse”). Neither of them can open the patient’s health record with
their key alone, therefore they should not be able to do so if they would collude. The solution
to this presented in [14] is that every user has a random number associated with their private
key which blinds the secret. If the same key has been used for all the decryption the secret can
successfully be ”unblinded”, but if different keys are used the blinding of the secret remains and
thus collusion will not work.
In an ABE system a key authority (or only authority) is needed to generate the users’ keys. This
authority is required to be fully trusted as it will issue all of the keys.
10
2.7.2 Multi-authority ABE
Having a single authority is simple but it has a few drawbacks. As all trust is put into one au-
thority the entire system (i.e. all files within the system) is compromised if this authority would
be corrupt or compromised in other ways. A well-designed multi-authority system distributes the
trust among different authorities such that several malicious/compromised authorities is needed to
compromise the entire system. Additionally one might want different authorities to issue different
attributes. For example there might be some national medical agency which keeps track of and
validates licenses for physicians and therefore it would be appropriate if they were an authority
and could issue the attribute Physician. Similarly it is most appropriate and convenient that a
hospital issues the attributes of working at this particular hospital, i.e. the hospital A would issue
the attribute Hospital A.
If a file would be encrypted under the policy: "Physician" AND "Hospital A" in the system
above, it would require two attributes from different authorities to successfully decrypt. In such a
system collusion resistance can not be achieved the same way as before, as it relied on one author-
ity using the same blinding (a random number per user) of the secret. In [22] a multi-authority
system (where any user can become an authority) is presented which is collusion resistant where
no central authority is needed to verify the keys. Instead every user in the system is assigned a
global identifier (GID) which acts as a linchpin for the keys issued by different authorities. Any
attempt of decrypting by combining keys issued for different GIDs will fail.
An elaborate solution such as [22] is not always necessary. If the policies that files are encrypted
under in the system only consist of attributes issued from one key authority then one can just
define a disjoint system per authority. This is implemented in [13] where everyone can be a key
authority but every key authority is associated with a separate public key i.e. every authority
defines a separate system. This means that a key can only consist of attributes from one authority.
In the article it is used for a privacy aware online social network where every user becomes a key
authority to generate keys to their “friends” to grant access to their statuses, photos e.t.c.
2.7.3 Key revocation

One of the benefits of ABE is when a new user enters the system or gets additional attributes
he/she just needs to get his/her key and everything will work as intended. The same is not true for
when a user’s privileges are being revoked. In order to enforce attribute-/key revocation re-keying
to all the authorized users is required.
In ICN another issue of key-revocation is present namely that the content encrypted under the
previous key might still be cached in a router. Removing such content by ordering all copies of
it destroyed might be impossible or at least severely damage the performance of the network. A
solution for immediate revocation in ICN, which is presented in [28], is to employ a proxy server
and split the content messages into two: one with the access structure and one with the data. The
access structure should be stored at the proxy. When a user wants to access this content he/she
will send two interest packets: one for the data and one for the access structure. In the access
structure interest packet the user will append his/her user id. The proxy will validate that this
user has not gotten his/her privileges revoked. If the user is authorized then a non-cacheable data
packet containing the access structure is sent to the user and the user can decrypt the content. If
the user is not authorized he/she can not decrypt the file as the access structure is missing. An
advantage of this system is that a change in the access policy to some content is immediate (as
the access policy is only stored at the proxy) and the already cached content can remain in the
network without being compromised.
2.7.4 Computational requirements

ABE is significantly more costly in terms of computations than other common public-key encryp-
tion methods such as RSA. In [13] it is stated that an ABE operation is between 100 - 1000 times
slower than those of RSA. This is often times not a problem if the calculations are done on a
11
workstation, but when mobile devices are considered the computational effort is one of the biggest
issues as it is also related to energy consumption.
Two factors which has a large impact on performance of ABE is the number of attributes in the
policy and the security level. Both are dependent on the application, but [17] mentions that it
is common to end up with quite complex access policies (i.e. many attributes) even in ordinary
applications and it is particularly true for access policies that contain integer comparison operators.
The computational effort needed for ABE operations scales linearly with the amount of attributes
in the system. Generally KP-ABE is faster than CP-ABE and especially for the algorithms
key-generation and encrypt [12, 34].
2.7.5 ABE on resource constrained devices

The combination of ICN and the Internet of Things (IoT) is quite natural as the many of the
applications in IoT are sensors collecting data for some purpose. The sensor data is then shared
across a network to users or other devices, for this sharing to be efficient ICN is a good option. In
case the data from the sensors contain private information one should enforce some access control
to ensure that the information stays private. As already mentioned ABE is a promising approach
for access control in ICN without losing the efficiency properties of ICN. In an ideal situation
one would like to perform the encryption at the source of the data before transmitting the data
across the network. However, the IoT devices are limited in computational power and ABE is an
expensive encryption type.
There are mainly two topics being discussed in research when considering ABE for resource con-
strained devices. These are ABE feasibility on mobile phones and ABE in sensor networks. When
discussing feasibility of ABE on mobile phones the question is usually about if the run time is
acceptable for a certain application rather than if the computations are possible to perform at
all, as the mobile phones are not resource constrained devices in a strict sense. Sensors are truly
resource constrained with microprocessors having RAM sizes ranging from 20 kB (or even less) to
1 MB, in contrast to modern mobile phones having processors with several cores and RAM sizes
of at least 512 MB.
Research regarding ABE feasibility on smartphones has been performed in [12, 34]. In [34] an
evaluation of ABE on an Android smartphone is presented with an ABE implementation in Java.
In the conclusions it is stated that the performance of ABE on mobile devices is too poor to be
acceptable even for the lowest security level (mainly based on execution time). This conclusion
is then questioned in [12] where the same measures are presented but for a C implementation on
Android. This implementation is considerably faster and in the conclusions it is stated that ABE
is definitely feasible on smartphones. However, the feasibility is dependent on the application as
the ABE operations for the highest security levels require 1 second per attribute in the policy for
the efficient C code.
Another idea which has been explored and presented in [17] is to outsource the decryption of
ABE to the cloud to reduce the expensive computations needed for a resource constrained device.
This greatly increases the performance of ABE on smartphones but it requires access to a third
party cloud/proxy and an Internet connection. Furthermore, initiating or resuming a cloud session
takes some time which is something that might make this less attractive depending on application.
In research regarding ABE in sensor networks it is common to not consider actually performing
the ABE operations on the sensor. Instead a common solution (with some variations) is for the
sensor to share a symmetric key with a server which is capable of doing the ABE operations. Thus
the sensor sends the data encrypted with symmetric key encryption to this powerful server. The
server encrypts the data with ABE and publishes it to the network. This is the case in [30] where
sensors monitoring peoples health share a symmetric key with a more powerful device. Another
similar idea is presented in [31] where the resource constrained nodes have unconstrained trusted
12
neighbor nodes which can support them in their calculations.
The straight-forward solution where the sensors perform the ABE operations is rarely discussed
because of its questionable feasibility. The gain of performing ABE on the sensors is that if it is
a multi-authority system, then there would be no trusted third party which can decrypt all the
data that the sensor publishes to the network.
2.7.6 The low-level operations of ABE

There are several different implementations and schemes of ABE, in this project the CP-ABE
scheme described in section 3, ”Our most Efficient Construction”, of [33] is implemented and thus
the operations described below is from that paper with some slight modifications to adapt it from
a symmetric pairing scheme to an asymmetric pairing scheme:
Setup: The setup algorithm takes no input and chooses two groups G1 and G2 of prime order p,
two generators g1 and g2 . In addition it chooses two random exponents b, α ∈ Zp . The public key
is published as:
P K = {g1 , g2 , e(g1 , g2 )α , g1b , g2b }
and the master secret key is set as M SK = α.
Keygen: The key generation algorithms takes the master secret key M SK and a set of attributes
S as input. The algorithm first chooses a random t ∈ Zp and then creates the private key as:
User key = {K = g2α g2bt , L = g2t , ∀x ∈ S : Kx = htx },
where hx is the attribute string of attribute x hashed to an element of G1 .
Encrypt: The encryption operation takes the public key P K, the message to encrypt and an
access policy A as input. The algorithm first chooses a random s ∈ Zp and computes
B = e(g1 , g2 )αs . (8)
B is then hashed to a symmetric key of 128 bits and used to symmetrically encrypt the message.
The access policy is then parsed to create an access tree. Shamir’s secret sharing is used to embed
the shares of the secret s in the nodes of the access tree. This is done by treating AND-gates as
a n of n secret sharing and OR-gates as a 1 of n secret sharing. The nodes of the access tree will
have a unique number i and a share si associated with them. The algorithm also chooses random
r1 , .., rn ∈ Zp . The ciphertext is published as
CT = {C = g s , Ci = g bsi h−r
i
i
, Di = g2ri },
together with the access policy and the symmetrically encrypted message.
Decrypt: The decryption algorithm takes as input a ciphertext CT for access policy A and a user
key for a set of attribute S. The lagrange basis polynomials evaluated at zero, ì (0), are computed
for the indices involved in A by Y xj
ì (0) = .
xj − xi
j∈A,i6=j
The decryption algorithm computes
e(C, K)
Q ì (0)
(9)
i∈A e(Ci , L)e(Di , Ki )
which can be rewritten to

e(g1s , g2bt g2α )
tì (0)
(10)
e((g1bsi h−r , g2t )e(hi , g2ri )
Q i ì (0)
i∈A i )
13
by replacing the variables to express it more explicitly. (10) can be further rewritten by using
properties of bilinearity which allows exponents to be interchanged since e(g1 , g2x ) = e(g1x , g2 ),
e(g1 , g2 )αs e(g1 , g2 )bst

bsi −ri
. (11)
, g t )ì (0) e(hri i , g t )ì (0)
Q
i∈A e(g1 hi
Additionally using the property e(R, T )e(S, T ) = e(RS, T ), yields
e(g1 , g2 )αs e(g1 , g2 )bst

Q bsi
. (12)
t ì (0)
i∈A e(g1 , g )
Since the only i-dependence is present in the exponent of the denominator it can be expressed as:
e(g1 , g2 )αs e(g1 , g2 )bst

P . (13)
e(g1 , g2 )bt i∈A si ì (0)
P
Recall the property of Lagrange basis polynomials, i si ì (0) = L(0) thus it recreates the coeffi-
cient at zero which is the secret s. Therefore (13) is:
e(g1 , g2 )αs e(g1 , g2 )bst

= e(g1 , g2 )αs (14)
e(g1 , g2 )bst
which is equal to the element B from (8). Thus, hashing (14) to a 128 symmetric key will yield
the exact same symmetric key which was used during encryption.
The scheme is using the Decisional Diffie-Hellman (DDH) assumption which loosely states that no
algorithm can efficiently differentiate on the tuples {g a , g b , g ab } and {g a , g b , g c } where a, b and c
are chosen randomly [33]. If this assumption would not hold then the system would not be secure.
14
3 Software
3.1 QEMU
QEMU is an emulation software, which supports a wide spectrum of CPUs, including micropro-
cessors. In this project it was used prior to acquiring hardware in order to see that the code
compiled and fit into the flash of the target device. The time required for encryption in QEMU
is significantly faster than on the actual device. This is because QEMU aims at being as fast as
possible in terms of emulation. Thus one can not run QEMU and expect the same performance
in terms of time. However, QEMU can be of use when determining feasibility. If the program
runs in QEMU then it will most likely run on the actual device too, albeit slower. Additional
information about QEMU can be found in [8].
3.2 Valgrind
Valgrind is a system for debugging and profiling Linux programs. Valgrind contains several tools
which can be useful while debugging but is most famous for its heap profiler. In this project
Valgrind is used to measure the RAM usage of different programs. This can be done by using
valgrind’s tool massif, the heap profiler, together with the flag --stacks=yes [10].
3.3 Relic-toolkit
The relic-toolkit is a cryptographic meta-toolkit with emphasis on efficiency and flexibility. The
relic-toolkit is used in the implementation in this project because of it’s platform flexibility which
includes support for Contiki and bare-metal applications. For more information about the relic-
toolkit and the source code see [9].
3.4 The Functional Encryption Library

The functional encryption library (libfenc) is an open-source library that contains implementation
for the KP-ABE scheme presented in [21] and a CP-ABE scheme presented in [33]. The authors
of the functional encryption library made the library publicly available as their paper [11] was
published. The paper evaluates their code on an iPhone 4. The functional encryption library is
dependent on the GMP library [4] and the PBC library [7]. For additional information about
libfenc and the source code see [3].
15
4 Hardware
4.1 Laptop
The laptop used in this was project had an Intel Core i5-2410M CPU @ 2.30 GHz x 4, and a
RAM size of 4 GB. The laptop runs Ubuntu 14.04. This laptop is from now on referred to as the
laptop.
4.2 Sensor
The sensor used in this project is equipped with a STM32L151VCT6 microcontroller which has
an ARM Cortex-M3 core with 256 kB flash and 32 kB RAM. The sensor has no operating system
which is referred to as bare-metal. This sensor is from now on referred to as the sensor.
16
5 Schemes
5.1 Scheme discussion
KP-ABE is the oldest of the two types of ABE, presented for the first time in [16] in 2006. Shortly
after, the paper introducing CP-ABE was published in [14] in 2007. In KP-ABE the attributes
describe the encrypted object and the private keys are policies based on these attributes. In
CP-ABE the attributes describe the users in the system and the encrypted objects are encrypted
according to policies based on these attributes. An example of CP-ABE is presented in Figure
3 and an example of KP-ABE is presented in Figure 4, both of them being in a school context.
In the CP-ABE example the file is encrypted such that only teachers at a particular school can
open it. In the KP-ABE example it is not trivial to determine who the recipient is, instead the
attributes describe the file and in this case one could imagine that the file is Jan Janson’s grades
and he is a student in class 9A at school A. CP-ABE is in a sense more intuitive than KP-ABE
at least seen from the encryptor’s point of view. By describing the users who may access the
content the encryptor know what attributes the recipients have. In contrast to KP-ABE where
it is non-trivial to determine who has access and therefore the responsibility of access control lies
more with the authority issuing the keys than the encryptor.
In figure 5 one can see time required for encryption for KP-ABE and CP-ABE on the laptop using
KP-ABE implementation [6] and CP-ABE implementation [1]. It is clear that the encryption
operation of KP-ABE is faster than the encryption operation of CP-ABE. Moreover, in Figure
6 the RAM requirements of KP-ABE and CP-ABE on the laptop can be seen as a function of
number of attributes. Considering both these figures it is clear that KP-ABE is computationally
cheaper than CP-ABE, both in terms of encryption time and RAM usage. The result displayed
in the two figures are consistent with the results presented in [34, 12] .
Figure 3: An example of CP-ABE. Figure 4: An example of KP-ABE.
17
Figure 5: The encryption time of CP- and KP-ABE on the laptop as a function of number of
attributes.
Figure 6: The RAM usage of CP- and KP-ABE on the laptop as a function of number of attributes.
With the knowledge of KP-ABE being computationally cheaper it is worthwhile considering using
KP-ABE if it is viable in the current application. However, this might be inconvenient for the
users performing encryption as the access control is shifted more heavily towards the authorities.
If this is acceptable in the considered application then KP-ABE is preferable in terms of compu-
tations, but if it is not acceptable then one might still want to utilize the knowledge of KP-ABE
being more lightweight than CP-ABE.
5.2 Simulated CP-ABE

A trivial way of trying to imitate CP-ABE with KP-ABE would be to tag the encrypted object
with attributes that the describes intended recipients, such as Teacher and Parent. However,
this tagging is ambiguous, should any teacher be able to decrypt the file or is it only users being
both a teacher and a parent that should be able to decrypt? Intuitively a user that is a teacher
should be able to decrypt an object only tagged with Teacher, thus the private key policy must
contain a segment which allows decryption if the Teacher attribute is tagged. However, having
such a part in the private key policy makes it impossible to enforce policies such as Parent AND
Teacher, because as long as the object is tagged with the Teacher attribute decryption is possible.
Therefore this scheme does not achieve the same expressiveness as CP-ABE, tagging an encrypted
18
object with: Teacher, Parent, effectively results in the policy Teacher OR Parent. Regardless
of the amount of attributes the object is tagged with they will be combined with OR, thus having
one of these attributes is sufficient to decrypt. This means it is essentially group encryption and
that is why it will be referred to as ”group KP-ABE”. Group encryption can also be achieved
in a simple way by using RSA, where a group is assigned a public key and each member of that
group has the corresponding private key. Thus group KP-ABE is an expensive way of performing
group encryption as it has already exists in less computationally expensive ways, thus employing
group KP-ABE is not beneficial as it comes with the cost of KP-ABE but only the expressiveness
of normal group encryption.
In [23] a more elaborate way to ”simulate” CP-ABE with KP-ABE is presented. This is done by
specifying a certain structure of the key policies. In the paper it is introduced because they already
employ KP-ABE in the system to encrypt personal health records among physicians but they also
want to allow the patient owning the personal health record to be able to share it in an easy and
expressive way to e.g. family or insurance company. For the purposes of user sharing CP-ABE is
more convenient than KP-ABE, therefore they introduce a method of mimicking CP-ABE with
KP-ABE which is referred to as ”simulated CP-ABE” from now on. In their paper the purpose
of simulated CP-ABE is solely for user convenience and not for potential performance gains. Em-
ploying simulated CP-ABE might potentially decrease the cost of encryption while maintaining
the intuitive way of using CP-ABE at the cost of expressiveness.
The simulated CP-ABE system is constructed in the following way: All private keys’ policy
structure will be the same and the general structure is shown in Figure 7. The top level AND gate
is between different authorities. The second level AND gate is between different attribute types
within this authority. The third level OR gate is between attributes of this attribute type. In every
attribute type there will exist a wildcard attribute ”∗” which every user in the system will have
regardless of clearance level. The wildcard attribute is helpful for the encryptor to specify ”do not
care about this attribute type”.
Figure 7: The policy structure of the private keys to simulate CP-ABE with KP-ABE. In the
image 11 indicates that it is from authority 1 and attribute type 1.
Examples of possible authorities could be Ericsson, Uppsala University (UU) or Swedish Insti-
tute of Computer Science (SICS). Different attribute types which Ericsson could have would be
position, department and other attributes. Among the type positions there could be the follow-
ing attributes: developer, manager, thesis student and ∗Ericsson position (the wildcard attribute for
authority Ericsson attribute type position). When encrypting in this system the encryptor must
specify at least one attribute from every attribute type there is. If one attribute type is not relevant
19
for a certain policy then the wildcard attribute of that type needs to be specified when encrypting.
An example of the general structure of the private keys in a simulated CP-ABE system can be seen
in Figure 8. In this example only one authority is considered, therefore it has only two levels, i.e.
the first AND gate is between different attribute types which in this case are position and depart-
ment. The second level gate is an OR gate between different attributes within the attribute type.
Everybody in the system will at least have the two wildcard attributes, ∗1 and ∗2 . If one wants to
encrypt a file to any developer in the network department then the ciphertext should be tagged
with: network, developer, which essentially will enforce the policy: network AND developer.
Another example could be if one wants to encrypt a file to anyone at the video department then
one tags the file with: ∗1 , video, which enforces the policy: video. An additional example could
be to encrypt a file to all the people working at the network or the video department. This is
done by tagging the ciphertext with: network, video, ∗1 , which enforces the policy: network
OR video.
The expressiveness is limited, for example the policy video OR manager can not be achieved in
the private key structure shown in Figure 8. However, some OR policies are possible to enforce
e.g. network OR video. This means that the one has to be careful during the construction of the
general structure of the private keys such that all desired policies actually can be achieved.
Figure 8: An example of how the general structure of the private keys in simulated CP-ABE could
look.
For certain systems this might be computationally cheaper than CP-ABE while maintaining an
intuitive way of specifying the policy. The systems where simulated CP-ABE can be beneficial is
when the CP-ABE policies are consistently about the same size in terms of number of attributes.
A benefit of simulated CP-ABE is that it requires no knowledge of the underlying computations
in order to implement in a system, albeit it might be cumbersome. Thus if there is a KP-ABE
implementation available, anyone with basic knowledge of the high level concepts of KP-ABE can
implement the simulated CP-ABE scheme.
The drawback of this scheme is that is scales poorly. Every encrypted object will be encrypted
with at least the number of attribute types there are in the system, because if an attribute type is
not required the wildcard of that type must be specified during encryption. This would be disas-
trous if the system size was 1000 attribute types and the desired policy only required 3 attribute
types, meaning an overhead of 997 attributes when encrypting. It also limits the flexibility, as
all private keys must have the same principal structure. These two properties indicate that this
system would not work on a global level, instead this scheme is suited for systems with a limited
amount of authorities.
20
6 System
6.1 System overview and scenario
In Figure 9 a conceptual image of the system considered is shown, where the sensors gather
sensitive data. This data is sent to a gateway which forwards it to the ICN network. Since the
data is sensitive it must be encrypted to protect it from unauthorized users. The gateway is not
a trusted entity and therefore the encryption must take place at the sensor. To fully utilize the
caching capabilities of the ICN network ABE is employed. This is a problem since ABE is costly
in terms of computations and the sensors are resource constrained.
Figure 9: A conceptual image of the system considered
6.2 Proposals
Two proposals are suggested to how ABE can be applied in such a system. In Figure 10 the same
system is shown but with the authority added which is a necessary entity for ABE to work. The
arrows represent communication and the dotted arrows are only present in proposal I and are
therefore not always needed. Both proposals will employ ABE, however they differ in where the
ABE operations are applied. The first system, the Authority ABE, does not require the sensors
to perform any ABE operations and in the other, the ABE sensor system, the sensors perform the
ABE operations. The first system works for any sensor capable of symmetric encryption and the
second system requires the sensor to be more powerful. Neither of these systems are novel. The
first system (with some variations) is what typically is used when ABE is considered in systems
with resource constrained devices. The second system is the straight-forward way of applying ABE
on a sensor, but it is rarely considered due to the questionable feasibility. Both of the systems
are agnostic to which ABE scheme is employed, i.e. they can employ any of the ABE schemes
described in section 5.
Figure 10: A conceptual image of the system with an authority included.
6.2.1 Proposal I - Authority ABE

In this system the sensor and an authority shares a symmetric key, indicated by the bottom left
dotted arrow in Figure 10. The sensors encrypt the data under the symmetric key. This encrypted
21
data is published to the network through the gateway. The sensor keeps the symmetric key pri-
vate. The authority can then proceed to encrypt the symmetric key with ABE under the desired
policy and publish this encrypted key to the network, this is represented by the bottom right
dotted arrow in Figure 10. The encrypted data from the sensor should include an identifier to the
symmetric key such that users requesting the encrypted data also can request the encrypted key.
To access the data from the sensors a user must successfully decrypt the symmetric key.
The advantage of this system is that the sensors only need to perform symmetric encryption,
which is a cheap operation, regardless of the policy. Thus, the work load for the sensor is small
and constant.
The biggest drawback of this system is that the authority, which shares the symmetric key with the
sensor, will be able to decrypt any message this sensor publishes as the authority has the symmetric
key. This system also requires end-to-end communication between sensor and authority.
6.2.2 Proposal II - Sensor ABE

If the sensors are powerful enough to perform ABE operations then one can reduce proposal I to
exclude the authority from the encryption. In this system the sensor would perform the encryption
single-handedly. This can be illustrated by Figure 10 by neglecting the dotted arrows, i.e. the
sensor gathers data which it encrypts under ABE and publishes to the network. In this system
the only purpose of the authority is to provide the users in the network with private keys.
The advantage of this system is that it requires no end-to-end communication between authority
and sensor. Additionally if the ABE system is multi-authority then there is no single third party
that can decrypt all the data.
The drawback is the computational requirement of the sensors, which limits the feasibility of the
system. The computations on the sensor will naturally be slower than on a more powerful server
which can potentially be an issue if time is an important factor. However, it is reasonable to
believe that the sensor will be encrypting for the same access policy repeatedly (as it will most
likely gather the same type of data for long periods of time), then the sensor does not have to
encrypt every data object it publishes with ABE encryption. Instead it encrypts under ABE for
the first data object and then uses the same symmetric key for a certain amount of time. This
way the sensor only has to perform ABE encryption when refreshing the symmetric key used for
encryption of the data.
22
7 Implementation
In this project an implementation of CP-ABE which runs on microprocessors bare-metal has been
written. The implementation is based upon the functional encryption library (libfenc) for CP-
ABE but rewritten to exclude the dependence of GMP and PBC and instead use the relic-toolkit.
The GMP and PBC library are not directly applicable to Contiki and bare-metal applications,
but it is possible that they can be changed to suit such applications. However, the relic-toolkit
officially supports Contiki and bare-metal applications which is why it was the preferred choice.
The process of rewriting libfenc required mainly changing the computational parts of the library.
Some parts of the PBC library does not have an exact counterpart in the relic-toolkit, thus re-
quiring more than just replacing a function call. The CP-ABE scheme description in [33] uses a
multiplicative notation and this is also the case for the PBC library, but the relic-toolkit uses an
additive notation.
The relic-toolkit and PBC both have the structure of function calls where the first input to the
function is where the result of the operation is stored, i.e. if the function call is func(c, a, b),
then the operation is performed with a and b and stored in c. Therefore if func would be the
addition operation then the function call func(c, a, b) computes c = a + b. In the relic-toolkit
the call func(a, a, b) is allowed and computes a = a + b, but that sort of overwriting is not
allowed in PBC.
The PBC library has one type and it is called element t. This type is used regardless if it is an
element of Zp , G1 , G2 or GT . In this sense the relic-toolkit has a more intuitive naming of the
types where fp t is an element of Zp , g1 t is an element of G1 , g2 t is an element of G2 and gt t
is an element of GT . The authors of libfenc put effort into naming their variables by appending
Z, ON E, T W O or T to the variable name to indicate which group it belongs to. This naming
convention is useful, but some functions accept any group element as input and proceeded to call
general functions such as element to hash() which works regardless of which group the element
actually belongs to. These general functions had to be replaced by a function for every group
element type with relic-toolkit.
The implementation achieves a 128-bit security level by using the pairing-friendly elliptic curve
BN P256 of the relic-toolkit.
In the description of the CP-ABE scheme in [33] (which the implementation is based on) it states
that the prime order of the elliptic curve groups G1 , G2 and GT should be the same as the prime
order of the finite field Zp . This makes the elliptic curve anomalous which is a weaker form of
elliptic curves in terms of security, i.e. there exists more efficient ways to break a scheme using
such a curve [20]. Most likely [33] described it this way to relieve the reader of unnecessary com-
plex expressions and instead focus on the scheme itself. libfenc uses an anomalous elliptic curve,
i.e. where the prime order of the elliptic curve groups are the same as the finite field. This is
not the case for the curve BN P256 of the relic-toolkit. This can potentially cause issues when
reconstructing the secret. If n is the prime order of G1 , G2 and GT and p is the prime order of
Zp . One has to make sure to share the secret and calculate the Lagrange basis polynomials in a
finite field modulus n (or also written Zn ), this is because the secret reconstruction takes place in
the exponent of the elliptic curve groups and thus work in Zn .
In a bare-metal application there is no built-in support for C calls to malloc() and free(), as
the memory allocation is usually handled by the operating system. The code in the libfenc library
was therefore rewritten to avoid as much dynamic memory allocation as possible. However, when
constructing the access tree in the beginning of the encryption algorithm it is hard not to use some
kind of dynamic memory allocation. Therefore a naive implementation of malloc() and free()
was written and used when the dynamic allocation could not be changed to static allocation. The
naive implementation can be seen in Listing 2. As one can see free() is not implemented, which is
the main reason to refrain from using this naive dynamic memory allocation unless it is absolutely
23
necessary.
Listing 2: A naive implementation of malloc() and free().
uint8 t h e a p [ HEAPSIZE ] = { 0 } ; // g l o b a l b y t e a r r a y
int h e a p I n d = 0 ; // g l o b a l i n t , k e e p i n g t r a c k o f i n d e x o f heap
u i n t 8 t ∗ n a i v e m a l l o c ( int b y t e s ) {
i f ( ( h e a p I n d + b y t e s ) >= HEAPSIZE ) {
p r i n t f ( ” A l l o c a t i o n f a i l e d : No heap memory l e f t ! \n” ) ;
return NULL;
} else {
h e a p I n d += b y t e s ;
return &( h e a p [ h e a p I n d ] ) ;
}
void n a i v e f r e e ( u i n t 8 t ∗ v a l ) {
// Do n o t h i n g
}
Another property of a bare-metal application is that there is no file system. Therefore the imple-
mentation has the public parameters of the system hard-coded, but it is possible to change it to
support reading in the public parameters as a byte array. The encryption is done by generating
the symmetric key and encrypting the data (in the format of a byte array) with this symmetric
key. The ciphertext, which contains the information needed for decryption, is also on the format
of a byte array. In a real application this ciphertext byte array and encrypted data would be
transmitted over the network, but in this project the ciphertext byte array has been printed to
the terminal instead in order to verify the computations of the sensor and make sure decryption
is possible.
24
8 Results
8.1 Sensor performance
In Table 2 the average run time of the main operations of the ABE on the laptop and the sensor
is shown. In particular one can note that randomizing elements in G1 , G2 or GT is a significant
operation requiring almost as much time as an exponentiation in the respective elliptic curve
group. One can also see that the sensor is several magnitudes slower than the laptop for all
operations, which is an expected result.
Table 2: The execution time of the main cryptographic operations on the laptop and the sensor.
Operation Time on laptop [s] Time on sensor [s]
rand. element in G1 7.7 · 10−4 0.12
rand. element in G2 4.7 · 10−3 1.12
rand. element in GT 5.6 · 10−3 0.90
exp. in G1 1.2 · 10−3 0.22
exp. in G2 3.6 · 10−3 1.16
exp. in GT 1.1 · 10−2 2.05
−6
mul. in G1 5 · 10 8 · 10−4
−5
mul. in G2 1.4 · 10 3.9 · 10−3
−5
mul. in GT 4.3 · 10 0.01
In Figure 11 the time needed for encryption at the sensor is shown as a function of number of
attributes in the policy. The line is not smooth, because the resolution on the time measurements
on the sensor is in seconds. If the bumps are neglected or smoothed out one can see that it is
a trend to being linear in number of attributes which is what is expected. Adding an attribute
to the policy adds between 1 to 2 seconds to the encryption time. For one attribute it takes 3
seconds which means that there is a small overhead of about 1 second as well. Therefore one can
pessimistically approximate the encryption time by enc time = 1 + 2 · nr attr. The policy size
ranges from 1 to 12 attributes, the upper limit is set because the sensor does not have sufficient
RAM to support larger policies.
Figure 11: The encryption time of CP-ABE on the sensor as a function of number of attributes.
In Figure 12 the RAM usage as a function of number of attributes is shown. The measurements
of RAM was taken with Valgrind on the laptop. Even though the laptop and the sensor have
different instruction sets it is reasonable to believe that the laptop RAM usage is representative
25
for the sensor RAM usage. This reasoning is based on the fact that the sensor, which has 32 kB
of RAM, could not perform encryption for policies of 13 attributes which on the laptop required
slightly below 32 kB of RAM.
Figure 12: The RAM usage on the laptop as a function of number of attributes.
The ciphertext, which is the additional overhead to an encrypted message with ABE, consists of
n + 1 g1 t elements, n g2 t elements, the policy string and a list of the attributes. In relic-toolkit
there are functions to compress elements of g1 t and g2 t and these can be utilized to reduce
message overhead. In Figure 13 the ciphertext size in bytes can be seen as a function of number
of attributes in the encryption policy. There are four lines in the figure, each corresponding to
different methods of reducing the ciphertext size.
One of these methods are utilizing built-in compression methods from the relic-toolkit. Compress-
ing the ciphertext introduces two new operations pack() and unpack(). pack() is fast and adds
a negligible overhead to the serilization function. unpack() significantly slows down the deserial-
ization process. The deserialization process is not part of the encryption operation so the sensors
will not be affected by this overhead. Additionally the deserialization process is a minor part of
the decryption algorithm, thus it will not affect the decryption time. It is therefore preferred to
compress the ciphertext.
The ciphertext structure contains the elements, a policy string and an attribute list. The attribute
list is necessary to have during the computations but it is derivable from the policy string. There-
fore if one wants to reduce the ciphertext size one can omit the attribute list from the serialization.
This reduces the time required for serialization but as it is a minor operation it has a negligible
impact on encryption time. However, it forces the decryptor to reconstruct the attribute list from
the policy. This reconstruction process infers a negligible overhead to the decryption algorithm.
26
Figure 13: The ciphertext size in bytes for different optimization techniques as a function of
number of attributes.
27
9 Discussion
9.1 System proposals and schemes
In the sensor ABE system one of the benefits listed is that there will exist no single third party
that can decrypt all the data if it is a multi-authority scenario. This is not true if the policy can
be satisfied by attributes from only one of these authorities as the system is essentially reduced
to a single authority system for this policy. Therefore the best case scenario, in terms of security,
is when attributes from several different authorities is needed to satisfy a policy.
In the authority ABE system, the authority is considered a powerful entity and it should have
no problem to perform the computations of CP-ABE. Therefore in the authority ABE system it
is less interesting to look into alternative schemes which limits expressiveness and flexibility to
reduce computational requirements. However, if it would be suitable to employ KP-ABE in the
system then it is also beneficial to do so from a computational point of view, but the simulated
CP-ABE is far less interesting for a computationally powerful system.
In the sensor ABE system, where the resource constrained sensors perform the encryption, all
options might be of interest. The first standpoint one should consider is if KP-ABE could be a
viable choice, if so it would be the most beneficial to employ in terms of computation. If CP-ABE
is preferred for the system one has to perform a comparison between simulated CP-ABE and CP-
ABE. Simulated CP-ABE is beneficial if the system contains a limited amount of authorities and
where the policies are about the same size in terms of number of attributes. Otherwise the CP-
ABE scheme is better, additionally the CP-ABE scheme does not limit the flexibility of policies
in the system.
9.1.1 Simple CP-ABE

In the paper where libfenc is introduced there are three different schemes that are evaluated [11].
These schemes are a KP-ABE scheme referred to as LSW (KP) in the paper and two CP-ABE
schemes referred to as WCP(CP) and WSCP(CP-lite). In the released version of libfenc there is
only support for two of these three schemes, WCP and LSW. The missing scheme, WSCP, has
the limitation that an attribute can only appear once within a policy, thus it is slightly limited
in expressiveness. The interesting part of this scheme is that it is significantly faster than the
WCP scheme and also the LSW scheme which is a KP scheme, this can be seen in Figure 14
(this figure is copied from [11] where it is Figure 6). There are no measurements of the RAM us-
age in [11] and because the public implementation is incomplete no such measurement is available.
The expressiveness limitation is small compared to the performance gain of WSCP, at least in
terms of time. A reasonable, slightly pessimistic, assumption is that it requires as much RAM as
the ordinary WCP scheme, even so it would still be a better choice than WCP. More information
about the RAM usage is needed to draw further conclusions, but this scheme is definitely of inter-
est. The issue is that the information provided in the paper [11] and at the website for libfenc [3]
differs in where the WSCP scheme can be found and it can not be found in any of the given papers.
Even if this scheme can’t be located it gives an idea of the fact that even more efficient schemes
might be available which does not compromise the expressiveness in a large extent. This is a
promising area to look further into for CP-ABE at the sensors.
28
Figure 14: The encryption times of the implementations presented in [11], note that the scale of
the y-axes are different. (This figure is copied from [11], where it is Figure 6).
9.2 Implementation
In the GMP library there exist a part called mini-gmp which is a scaled down version of GMP
intended for usage in applications where the full GMP library not viable. However, the PBC
library is dependent on parts of the GMP library which is not in the mini-gmp library, but it
might still be possible adding these parts from the GMP library to mini-gmp, if one want to use
PBC rather than relic-toolkit.
The implementation has room for improvements. In particular there exists a library for the sensor
which utilizes built-in hardware support for some cryptographic operations. Using this library
could potentially reduce the time needed for encryption and should therefore be further investi-
gated.
Additionally it could be interesting adding support for KP-ABE in the implementation and per-
forming experiments for comparison between CP and KP-ABE. This would be useful for applica-
tions where both CP and KP-ABE is a viable choice. Furthermore, an implementation of KP-ABE
would enable measurements and analysis of the simulated CP-ABE scheme too.
The current implementation only has support for a security level of 128-bit, which is considered
a quite high security level. In some applications a lower security level might suffice e.g. 112-bit
security. Lowering the security level will reduce both encryption time and RAM usage [12], essen-
tially making larger policies viable.
The two methods to reduce the ciphertext size are cheap and reduce the size significantly, there-
fore it is recommended to use both of these methods. Both of the methods are supported in the
implementation, but the option to not compress the elements exists as well.
The size of the ciphertext is also dependent on the security level as the elements of the ciphertext
reduces in size when the security level is reduced. In 128-bit security a g1 t element requires 65
bytes if unpacked or 33 bytes if packed. A g2 t element requires 129 bytes unpacked or 65 bytes
if packed. In 112-bit security a g1 t element requires 57 bytes unpacked and 29 bytes packed, a
g2 t element requires 113 bytes unpacked or 57 bytes packed. In general a certain security level
x is achieved by having a prime field of size 2x. A g1 t element requires 2 prime field elements
unpacked or 1 prime field if packed and an additional byte, whereas a g2 t element requires 4
prime field elements unpacked or 2 prime field elements if packed and an additional byte and the
prime field elements are of size 2x bytes.
29
9.3 Results
As earlier mentioned, multiple-authority (MA) ABE is where the gain of performing the ABE
operations on the sensors would be the largest as the trusted third party is removed. In general,
MA-systems increase the complexity of the encryption and decryption operations. It is still likely
that these operations are feasible on sensors of the type used in this thesis project, but future
work could include investigating performance of MA-ABE encryption on this sensor.
In the current encryption time tests the resolution of the measurements are in seconds, which is a
poor resolution. It suffices to give an idea of the running time but more accurate measurements
would give results that are in agreement with other ABE papers discussing ABE encryption time
such as [14, 12, 34], namely that the time is linear in number of attributes.
A common measure in the Internet of Things context is energy consumption, as many of the
devices are powered by battery. Performing experiments and comparing the results of the energy
consumption for the sensors in the two different systems presented here would be useful to draw
further conclusions of the feasibility of ABE on sensors.
The sensors that are deployed in the Green IoT project are running the operating system Con-
tiki. Contiki will infer some overhead and therefore it could be relevant to investigate how the
performance of the encryption is affected by running Contiki on the sensors.
30
10 Conclusions
Performing ABE on sensors is possible for systems where the policy size is rather small and when
time is not a scarce resource. However, the time issue has a solution which might suffice in some
applications. The solution is to use the same symmetric key from ABE encryption for a certain
amount of time and only refresh it when needed. This way the sensor does not have to perform
the expensive ABE operations for every data packet it sends.
The bottleneck of performing ABE on the sensors is the RAM size of the sensors.
In terms of which system solution to use the sensor ABE system is the recommended one, if it
is feasible. This is because it removes the need for end-to-end communication between authori-
ty/server and sensor and it removes the trusted third party which can decrypt all the sensor data.
If it is a single authority and end-to-end communication between authority and sensor is possible
then it doesn’t really matter which system one chooses. However, if end-to-end communication is
problematic and one must introduce a new trusted third party in addition to the authority, such as
a server, then it is beneficial to go with the sensor ABE system as this additional party is abundant.
If the authority ABE system, i.e. the system where the sensor and authority share a symmetric
key, is to be used it is not worthwhile putting effort into designing a simulated CP-ABE system
as the authority is powerful. The CP-ABE system is more intuitive and there is no reason to
give up this system on the basis of computational efficiency in the authority ABE case. However,
if KP-ABE is a viable choice for the application then it should be chosen from a computational
efficiency point of view.
When the sensor ABE system is being considered one could first see if KP-ABE would be a viable
choice, if so then use it. If the expressiveness of CP-ABE is necessary then one should make a
thorough comparison between CP-ABE and simulated CP-ABE. Simulated CP-ABE is beneficial
if the system contains a limited amount of authorities and where the policy sizes does not differ
much. Otherwise the CP-ABE scheme is better, additionally the CP-ABE scheme does not limit
the flexibility of policies in the system.
The most promising suggestion to improve the implementation is to use the library which utilizes
the built-in hardware support for some cryptographic operations. Additionally, the Simple CP-
ABE scheme is of particular interest for future implementations.
31
11 Acknowledgements
I want to thank my supervisors Börje Ohlman and Edith Ngai for making this project possible
and giving me the opportunity to perform my thesis work at Ericsson. I also want to send my
appreciation to the collaborators of the Green IoT project and Vinnova, who is co-funding the
Green IoT project. In particular I would like to thank Adrian Caragea at Upwis AB for helping me
get started with the sensor Upwis provided me with and Christian Rohner at the IT-department
of Uppsala University for reviewing my thesis.
32
References
[1] CP-ABE implementation
http://hms.isi.jhu.edu/acsc/cpabe/
[2] Cryptographic key length recommendation
https://www.keylength.com/
[3] Functional Encryption Library
https://code.google.com/archive/p/libfenc/
[4] Gnu MP Bignum (GMP) Library
https://gmplib.org/
[5] Green IoT Webpage
http://user.it.uu.se/∼eding810/GreenIoT/
[6] KP-ABE implementation
https://github.com/gustybear/kpabe
[7] Pairing-Based Cryptography (PBC) library
https://crypto.stanford.edu/pbc/
[8] QEMU
http://wiki.qemu.org/Main Page
[9] relic-toolkit, D. F. Aranha and C. P. L. Gouvêa, RELIC is an Efficient LIbrary for Cryptog-
raphy, https://github.com/relic-toolkit/relic
[10] Valgrind
http://valgrind.org/
[11] J.A. Akinyele, C.U. Lehmann, M.D. Green, M.W. Pagano, Z.N.J. Peterson A.D. Rubin, Self-
Protecting Electronic Medical Records Using Attribute-Based Encryption, Cryptology ePrint
Archive, Report 2010/565, http://eprint.iacr.org/, 2010.
[12] M. Ambrosin, M. Conti, T. Dargahi, On the Feasibility of Attribute-Based Encryption on
Smartphone Devices, arXiv:1504.00619
[13] R. Baden, A. Bender, N. Spring, B. Bhattacharjee, D. Starin, Persona: An online so-
cial network with user-defined privacy, SIGCOMM Computer Communications Review,
39(4):135–146, 2009.
[14] J. Bethencourt, A. Sahai, B. Waters, Ciphertext-Policy Attribute-Based Encryption, In: IEEE
Symposium on Security and Privacy, pp. 321-334 (2007)
[15] C. Ghali, M. Schlosberg, G. Tsudik, C. A. Wood, Interest-Based Access Control for Content
Centric Networks, arXiv:1505.06258
[16] V. Goyal, O. Pandey, A. Sahai, B. Waters, Attribute Based Encryption for Fine-Grained
Access Conrol of Encrypted Data, In ACM conference on Computer and Communications
Security (ACM CCS), 2006.
[17] M. Green, S. Hohenberger, B. Waters, Outsourcing the Decryption of ABE Ciphertexts,
InUSENIX Security Symposium, page 3, 2011.
[18] M. Hazewinkel, Cyclic Groups, Encyclopedia of Mathematics (2001)
[19] J. Kurihara, E. Uzun, C. A. Wood, An encryption-based access control framework for content-
centric networking, in Proc. IFIP Networking 2015, May 2015.
[20] F.Leprevost, J.Monnerat, S.Varrette, S. Vaudenay, Generating anomalous elliptic curves,
Information Processing Letters 93, 2005, pp.225-230.
33
[21] A. Lewko, A. Sahai, B. Waters, Revocation Systems with Very Small Private Keys, Proceed-
ings of the 2010 IEEE Symposium on Security and Privacy, p. 273-285, 2010
[22] A. Lewko, B. Waters, Decentralizing Attribute-Based Encryption, Cryptology ePrint Archive
Report 2010/351 (2010), http://eprint.iacr.org/
[23] M. Li , S. Yu , Y. Zheng , K. Ren, W. Lou, Scalable and secure sharing of personal health
records in cloud computing using attribute-basedencryption, IEEE Trans. Parallel Distrib.
Syst., vol. 24, no. 1, pp. 131-143, 2013
[24] A. Liu, P. Ning, TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wire-
less Sensor Networks, in Proceedings of the 7th International Conference on Information
Processing in Sensor Networks (IPSN 2008), SPOTS Track, pages 245–256, April 2008.
[25] P. Mahadevan, CCNx 1.0 Tutorial, PARC, Tech. Rep., March 2014
[26] L. B. Oliveira, M. Scott, J. Lopez, R. Dahab, TinyPBC: Pairings for authenticated identity-
based non-interactive key distribution in sensor networks, Cryptology ePrint Archive, Report
2007/482, 2007. http://eprint.iacr.org/.
[27] A. Shamir, How to share a secret, Communications of the ACM 22 (11): 612-613
[28] R. S. da Silva, S. D. Zorzo, An Access Control Mechanism to Ensure Privacy in Named Data
Networking using Attribute-based Encryption with Immediate Revocation of Privileges, IEEE
CCNC 2015
[29] J.H. Silverman, The Arithmetic of Elliptic Curves. Graduate Texts in Mathematics, 106. 1986,
Springer-Verlag.
[30] Y-L. Tan, B-M. Goi, R. Komiya, S-Y. Tan, A Study of Attribute-Based Encryption for Body
Sensor Networks, Informatics Engineering and Information Science (2011): 238-247
[31] L. Touati, Y. Challal, A. Bouabdallah, C-CP-ABE: Cooperative Ciphertext Policy Attribute-

Based Encryption for the Internet of Things, International Conference on advanced Network-
ing, Distributed Systems and Applications, 2014, Béjaia, Algeria. pp. 64-69, 2014.
[32] J.P. Walters, Z. Liang, W. Shi, V. Chaudhary, Wireless Sensor Network Security: A Survey,
Security in Distributed, Grid and Pervasive Computing Yang Xiao (Eds), year 2006
[33] B. Waters, Ciphertext-Policy Attribute-Based Encryption: An Expressive, Efficient,

and Provably Secure Realization, Cryptology ePrint Archive Report 2008/290 (2008),
http://eprint.iacr.org/
[34] X. Wang, J. Zhang, E. M. Schooler, M. Ion. Performance evaluation of attribute-based en-
cryption: Toward data privacy in the IoT, In ICC’14, 2014
34

Attribute-Based Encryption in Systems With Resource Constrained Devices in An Information Centric Networking Context

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Attribute-Based Encryption in Systems With Resource Constrained Devices in An Information Centric Networking Context

Uploaded by

Copyright:

Available Formats

UPTEC F 16037

Teknisk- naturvetenskaplig fakultet

Handledare: Börje Ohlman

1.1 Project description

2.1.1 Content Centric Networking

2.1.2 Security in ICN

2.2.1 Symmetric key encryption

2.2.2 Public key cryptography

2.2.3 Security levels

2.4 Mathematical tools

2.4.1 Cyclic group

2.4.2 Finite fields

2.4.4 Multiplicative and additive notation

If G1 = G2 the pairing is called symmetric otherwise it is an asymmetric pairing i.e. when

2.4.6 Lagrange polynomial

2.5 Shamir’s Secret Sharing Scheme

P (x) = a0 + a1 x + · · · + ak−1 xk−1 (5)

then the secret can be reconstructed by

2.6 Security on sensors

2.7 Attribute-based encryption

2.7.3 Key revocation

2.7.4 Computational requirements

2.7.5 ABE on resource constrained devices

2.7.6 The low-level operations of ABE

User key = {K = g2α g2bt , L = g2t , ∀x ∈ S : Kx = htx },

where hx is the attribute string of attribute x hashed to an element of G1 .

B = e(g1 , g2 )αs . (8)

The decryption algorithm computes

which can be rewritten to

e(g1 , g2 )αs e(g1 , g2 )bst

Additionally using the property e(R, T )e(S, T ) = e(RS, T ), yields

e(g1 , g2 )αs e(g1 , g2 )bst

e(g1 , g2 )αs e(g1 , g2 )bst

e(g1 , g2 )αs e(g1 , g2 )bst

3.4 The Functional Encryption Library

Figure 3: An example of CP-ABE. Figure 4: An example of KP-ABE.

5.2 Simulated CP-ABE

Figure 9: A conceptual image of the system considered

Figure 10: A conceptual image of the system with an authority included.

6.2.1 Proposal I - Authority ABE

6.2.2 Proposal II - Sensor ABE

9.1.1 Simple CP-ABE

[31] L. Touati, Y. Challal, A. Bouabdallah, C-CP-ABE: Cooperative Ciphertext Policy Attribute-

[33] B. Waters, Ciphertext-Policy Attribute-Based Encryption: An Expressive, Efficient,

You might also like