Smart Products

SmartProducts
Proactive Knowledge for Smart Products
SmartProducts
D4.2.2: Final Concept for Security and Privacy of

Proactive Knowledge
WP 4 – Storage & Distribution of

Proactive Knowledge
Deliverable Lead: TU Darmstadt
Contributing Partners:
TU Darmstadt
Delivery Date: 01.02.2011
Dissemination Level: Public
Version 1.0
Copyright  SmartProducts Consortium 2009-2012

SmartProducts WP 4 – Storage & Distribution of Proactive Knowledge
Deliverable D4.2.2: Final Concept for Security and Privacy of Proactive Knowledge
Deliverable Lead
Name Organisation e-mail
Matthias Beckerle TU Darmstadt beckerle@tk.informatik.tu-darmstadt.de
Contributors
Matthias Beckerle TU Darmstadt beckerle@tk.informatik.tu-darmstadt.de
Internal Reviewer
Mathieu D'Aquin OU m.daquin@open.ac.uk
Pascale Hugues EADS pascale.hugues@eads.net
Disclaimer
The information in this document is provided "as is", and no guarantee or warranty is given
that the information is fit for any particular purpose. The above referenced consortium
members shall have no liability for damages of any kind including without limitation direct,
special, indirect, or consequential damages that may result from the use of these materials
subject to any liability which is mandatory due to applicable law. Copyright 2011 by
TU Darmstadt.
SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 1

Revision Chart
Table 1: Revision chart in relation to [D4.2.1]
Section Status1 Old Section Description

1 u 2 Security related introduction
2 u 3 and 4 Added attacks on smart products
3 n Definition of Security Terms
4 u 5.4.2 Major update for Authentication
5 u 5.3 and 5.4.1 Text is now more concise
Added Access Control - constraints and Access Control
-formalizations
6 u 7 Conclusion only security related
A u 6 Requirements table updated and moved to the annex
1
Status: n = new, u = updated, r = removed

Table of Contents
LIST OF FIGURES ................................................................................................................................................ 5
LIST OF LISTINGS ............................................................................................................................................... 6
LIST OF TABLES .................................................................................................................................................. 7
EXECUTIVE SUMMARY .................................................................................................................................... 8
1 INTRODUCTION ........................................................................................................................................... 9
2 GOALS AND CHALLENGES ..................................................................................................................... 11
2.1 GOALS .................................................................................................................................................. 11

2.1.1 Reliable Security ................................................................................................................... 11
2.1.2 Usable Security ..................................................................................................................... 11
2.1.3 Reliable versus Usable Security ............................................................................................ 11
2.2 FOCUS OF SMARTPRODUCTS SECURITY ............................................................................................... 11
2.3 ATTACKS ON SMART PRODUCTS .......................................................................................................... 12
2.3.1 Identity theft........................................................................................................................... 13
2.3.2 Denial-of-Service (DoS) attacks ............................................................................................ 13
2.3.3 Sniffing network traffic .......................................................................................................... 14
3 APPROACH .................................................................................................................................................. 16
3.1 DEFINITION OF SECURITY TERMS .......................................................................................................... 16

3.1.1 Confidentiality ....................................................................................................................... 16
3.1.2 Integrity ................................................................................................................................. 16
3.1.3 Authenticity ........................................................................................................................... 16
3.1.4 Authorization ......................................................................................................................... 16
3.2 CIA, AUTHORIZATION, AND SMART PRODUCTS ................................................................................... 16
3.2.1 Confidentiality ....................................................................................................................... 16
3.2.2 Integrity ................................................................................................................................. 17
3.2.3 Authentication ....................................................................................................................... 17
3.2.4 Authorization ......................................................................................................................... 17
4 RELIABLE AND USABLE AUTHENTICATION .................................................................................... 18
4.1 RELATED WORK ................................................................................................................................... 18

4.1.1 Authentication by Knowledge ................................................................................................ 19
4.1.2 Authentication by Possession ................................................................................................ 21
4.1.3 Authentication by Biometrics ................................................................................................ 23
4.1.4 Multifactor Authentication .................................................................................................... 25
4.1.5 Taxonomy .............................................................................................................................. 26
4.2 RELIABLE AUTHENTICATION ................................................................................................................ 26
4.2.1 Reliable Authentication Methods .......................................................................................... 26

4.3 USABLE AUTHENTICATION ................................................................................................................... 28

4.3.1 Interaction Time .................................................................................................................... 28
4.3.2 Interaction Complexity .......................................................................................................... 29
4.3.3 Behavioural Predictability .................................................................................................... 29
5 RELIABLE AND USABLE ACCESS CONTROL .................................................................................... 31
5.1 RELATED WORK ................................................................................................................................... 31

5.1.1 Blacklist ................................................................................................................................. 31
5.1.2 MAC / DAC ........................................................................................................................... 32
5.1.3 RBAC ..................................................................................................................................... 32
5.1.4 ABAC ..................................................................................................................................... 32
5.1.5 Hybrid approaches ................................................................................................................ 32
5.2 RELIABLE ACCESS CONTROL ............................................................................................................... 33
5.2.1 Multilevel Access Control for Smart Products ...................................................................... 33
5.2.2 Cooperative Intrusion Detection ........................................................................................... 35
5.2.3 Usability ................................................................................................................................ 38
5.3 FORMALIZATION OF ACCESS RULES ..................................................................................................... 39
5.3.1 General terms ........................................................................................................................ 39
5.3.2 Entities................................................................................................................................... 40
5.3.3 Objects................................................................................................................................... 40
5.3.4 Access- and Deny-Rules ........................................................................................................ 40
5.3.5 Decision sets .......................................................................................................................... 41
5.4 CONSTRAINTS FOR ACCESS CONTROL .................................................................................................. 42
5.4.1 Reliability constraint S1: specific (permissive) rules. ........................................................... 42
5.4.2 Reliability constraint S2: meaningful rules. .......................................................................... 42
5.4.3 Usability constraint U1: no redundant rules. ........................................................................ 43
5.4.4 Usability constraint U2: consistent rules. ............................................................................. 43
5.4.5 Usability constraint U3: general, understandable and manageable rule sets. ..................... 43
5.4.6 Usability constraint U4: minimum number of rules. ............................................................. 43
5.5 ACCESS RULE GENERATION ................................................................................................................. 44
5.5.1 Automatic Rule Learning....................................................................................................... 44
5.5.2 Constrains Solving Algorithm ............................................................................................... 46
6 CONCLUSION AND OUTLOOK ............................................................................................................... 47
ANNEX .................................................................................................................................................................. 48
A REQUIREMENTS ........................................................................................................................................ 49
B GLOSSARY ................................................................................................................................................... 52
C LIST OF ACRONYMS ................................................................................................................................. 54
REFERENCES ..................................................................................................................................................... 55

List of Figures
Figure 1: Different Methods of Authentication .......................................................................... 19

Figure 2: Standard Way to Implement Authentication by Knowledge ...................................... 20
Figure 3: Standard Way to Implement Authentication by Possession ....................................... 22
Figure 4: Standard Way to Implement Authentication by Biometrics ....................................... 24
Figure 5: A Taxonomy of Authentication Mechanisms ............................................................. 26
Figure 6: Theoretical comparison of different AC models. ....................................................... 34
Figure 7: Different IDS [Debar-1999]........................................................................................ 36

List of Listings
Listing 1 Constrains Solving Algorithm .................................................................................... 46

List of Tables
Table 1: Revision chart in relation to [D4.2.1]............................................................................. 2

Table 2: Different Authentication by Knowledge Mechanisms ................................................. 20
Table 3: Different Authentication by Possession ....................................................................... 22
Table 4: Different Authentication by Biometrics ....................................................................... 24
Table 5: Mapping of Concepts and Requirements ..................................................................... 49

Executive Summary
WP4 provides secure storage and distribution services for the smart products platform. In task
4.2 the related security mechanisms for smart products are designed. In this Deliverable
reliable security mechanisms for smart products are developed that can satisfy the extended
needs for usability of non expert users that will handle this devices in the future.
A general analysis of the SotA of security current literature shows that for the security goals
integrity and confidentiality sufficient procedures exist, than can be adapted for smart products
needs, but there are gaps regarding authentication and access control. An in-deep analysis of
authentication and access control for smart products leads to the multi-Level Authentication
and multi-layer interactive rule-learning solutions.
The idea of multi-level authentication is to combine authentication based on knowledge,

possession and biometrics. This allows for usability and reliability combined with a maximum
of flexibility regarding authentication of users.
Multi-layer interactive Rule-learning tackles the problem of usability and security in access
control mechanisms especially regarding the generation of proper access control rule sets. A
theoretical solution for this challenge is presented using the combination of automatic rule
learning and user interaction which results is the interactive rule learning approach. Interactive
rule learning is designed to complete attribute-based access control to generate concise rule
sets even by non-expert end-users. The resulting approach leads to adaptive access control rule
sets that can be used for smart products.

1 Introduction
Smart products are a new class of devices that bridge the gap between the real and the virtual
world. They provide a natural and purposeful product-to-human interaction and context-aware
adaptivity. Smart products need to have knowledge about the application and environment that
they are immersed to fulfil their tasks. Thus, they also need access to private/confidential
information, such as users' preferences. Moreover, smart products can exchange
private/confidential information among each other to complete collaborative tasks that require
information from multiple sources, such as the booking of flight tickets and hotels. Smart
products can be part of highly dynamic environments, where devices can appear and disappear
in non-predictable ways.
However, the amount of possible security breaches is increasing with the sheer number and
variety of smart products. Equally, the variety of devices with different user interfaces also
increase the complexity of administrative tasks for the end-users. Therefore, one of the main
challenges of IT-security regarding smart products is the design of mechanisms that combine a
customizable level of security and usability [Beckerle-2009a, Cranor-2005].
Current IT-security solutions tend to overstrain non-expert users. In home and enterprise
environments, users are frequently forced to choose passwords for local and remote
authentication and also define rules for access control, e.g., file sharing access rights. However,
the imposition of such security features often lead to insecure or unpractical measures, such as
written passwords and access control rules that are often too general. In addition, users tend to
deactivate security mechanisms or render them useless by: not changing default passwords or
leaving them blank; granting access to everyone; or turning off basic security mechanisms.
This behaviour is very common nowadays, especially regarding login passwords, browser
cookies, virus scanners, and file access controls [Cranor-2005].
The administration of secure features in computational systems by non-expert end-users is

already a challenge. Such a fact can be easily shown by the massive number of computers that
are part of bot nets [Reding-2009], which is, in most of cases, caused by inability of such users
to keep their systems up-to-date or to change default settings. Smart products add more
complexity to such scenarios by increasing the administrative burden to the end-users.
In this deliverable, the usability aspects of security solutions are analyzed and mechanisms that
allow more user-friendly access control rules generation and flexible multi-factor
authentication are proposed. The initial analysis is used to identify usability gaps in basic

security mechanisms that can be applied for smart products. Such an analysis shows that there
are already sufficient solutions that can applied for confidentiality, integrity, and partly for
authentication services, but no appropriate access control solutions exist nowadays.

2 Goals and Challenges
2.1 Goals
The SmartProducts project aims at developing a generic platform for realising smart products
that accounts for their specific characteristics and challenges and provides a comprehensive set
of functionality such as communication facilities, multimodal product-to-user interaction, as
well as context acquisition and processing. WP4 contributes to this platform by developing
mechanisms for the secure storage and distribution of proactive knowledge in distributed,
heterogeneous and dynamic environments during the entire life-cycle of smart products.
Secure therefore means that the security mechanisms are reliable and usable as defined next.
2.1.1 Reliable Security

In this deliverable we define reliable security as a set of security mechanisms that is able to
fulfil the security specifications of an end-user regarding their security requirements.
2.1.2 Usable Security

In this deliverable usable security means that security mechanisms demand minimum user
interference to be deployed. A smart product should stay as usable as it would be without
security-mechanisms. Thus, the introduction of security should be preferably automated.
2.1.3 Reliable versus Usable Security

The aforementioned terms reliable and usable security can be seen as contradicting goals,
especially regarding access control rules. Such contradiction is e.g. resulting from the huge
amount of rules that are required to secure a system, which makes them unintelligible for end-
users. Usability in most cases is simply neglected, what can result in insecure systems in the
long-term since users tend to turn such security features off or use them in improper ways, as
mentioned in Section 1. In the remainder of this deliverable the term CIA is used as an
abbreviation for the security services confidentiality, integrity, and authentication. This usage
deviates from the more common usage of the term, which refers to confidentiality, integrity,
and availability.
2.2 Focus of SmartProducts Security

The development of security mechanisms for smart products is in many ways a great challenge.
Heterogeneity, resource limitations, high mobility, and the decentralisation of smart products
are just some of the properties that are part of their challenging nature. However, security is
just a major aspect of the SmartProducts project but with few resources (18PMs over the whole
project duration of 3 years). For that reason, we decided to focus on the main security features

relevant for SmartProducts, which are access control for proactive knowledge and multi-level
authentication. Other security issues like, integrity, and encryption of data are also very
important for smart products, but they are not smart products-specific and considered by many
other research projects (e.g., Mosquito2, Awareness3, or Prime4). For those reasons and as they
have the lowest impact on the whole project, we will not consider these issues in the
SmartProducts project. We think it is better to conceive the main aspects well and to leave the
other issues for future extensions of the smart products platform or to make use of state-of-the-
art solutions.
As pointed out in [D4.1.1], access control is fundamental to realise privacy. Furthermore, it is

needed to ensure that confidential proactive knowledge can only read by authorised entities.
This is important for private user data and manufacturer data like maintenance and
repair information.
However, access control alone is not sufficient to preserve user privacy and manufacturer data.
If an attacker is able to circumvent authentication mechanisms by exploiting bugs, viruses, or
Trojan horses to pass herself off as a device already part of a smart products network, she is
able to manipulate proactive knowledge with the full rights of the device taken over without
being noticed. For that reason, enhanced intrusion detection is indispensable to defend against
identity theft and exposition of software and/or hardware bugs. It allows for detecting
misbehaviour of already authenticated entities and acts as a second line of defence. Access
control alone can only properly operate under the assumption that the attacker is not able to act
in the name of another entity. In contrast, intrusion detection also works out if the attacker is in
disguise and hides in the network, which can happen especially in a smart product environment
as participants are expected to dynamically join and leave the network and due to the
heterogeneity of smart products. For that reason, we will further address cooperative intrusion
detection as this represents a new research challenge arising with smart products.
2.3 Attacks on Smart Products

The aspects of user-interaction and network capabilities that are integral part of Smart Products
require special attention to the following three types of attacks. Note that other attacks on
computer systems apply to Smart Products, too. The following three attacks are of special
importance for Smart Products.
2
http://www.mosquito-online.org
3
http://www.freeband.nl; http://ercim-news.ercim.org/content/view/261/435/
4
https://www.prime-project.eu/

2.3.1 Identity theft

Entity authentication can be achieved by at least one of the three basic authentication methods.
Successful authentication is a verified identity claim.
To steal an identity, the attacker either has to forge such a claim or generate a claim by passing
authentication procedures with a forged identity. In the last case, the system generates the
authenticator for the attacker. To use a forged claim, the attacker has to generate it and inject it
directly into the system, e.g. on network level. Consider a cookie or session id for websites.
The attacked entity will accept the forged authenticator without noticing that it is invalid.
In many scenarios, it is easier for an attacker to attack the authentication procedure directly.
The Smart Product will falsely recognize the attacker as a valid user granting all rights which
are associated with the valid user. In case of password authentication, an attacker could get
aware of a user’s password and supply it to the system along with the user’s identification (e.g.
a username). This results in a stolen identity [Berghel-2000].
A common countermeasure against identity theft is to harden authentication procedures.

Multifactor authentication requires entities to supply several proofs for their authenticity. These
proofs should cover different factors, e.g. a password and a biometric trait. In this case, if a
single authentication procedure fails to withstand the attacker, security is still guaranteed by the
other authentication procedures. An attacker has to break all authentication procedures to steal
an identity. This leads to a higher security than more complex single-factor authentication
procedures which require the attacker to break only one concept of authentication.
2.3.2 Denial-of-Service (DoS) attacks

A DoS attacker floods the attacked system with requests. The attacker’s goal is to render the
system unusable for valid users. This is usually accomplished by overloading the attacked
system which increases the response times or by crashing the system (e.g. no more memory
available) which leads to no responses at all. In all scenarios this would lead to unusable smart
products. This can be fatally if smart products have important application areas. At least it
would cause unsatisfied end-users.
There are two ways to prevent DoS attacks: Limit the requests an entity can pose over a
specific time or increase computational power and resources of the Smart Product which
processes the authentication requests. The first measure can be easily implemented. It may
decrease usability: consider a system that allows only five login attempts via password within a

timespan of fifteen minutes. In case a valid user mistypes her password five times, system
access is blocked until the end of this timespan.
For Smart Products with limited computational resources, this is often the only way to handle
DoS attacks. In many cases, an attacker possesses enough resources to overload every amount
of supplied resources on the victim’s side. Distributed-Denial-Of-Service (DDoS) attacks
distribute the attacker’s requests over large networks. It is unfeasible to counter such an attack
by increasing local capabilities [Mirkovic-2004].
2.3.3 Sniffing network traffic

The Dolev-Yao attacker model [Dolev-1983] commonly used in IT security describes an
attacker that is able to read, inject, suppress and modify data sent over a network. Note that
reading data does not necessarily mean understanding it. Encrypted data can be read, but
provides no information to the attacker than its existence itself. The attacker only knows that
something has been sent. Business secrets could be read and all different types of Data could
be manipulated. A very high amount of damage could be done by selling this information to
business competition. Also sabotage is quite easy if an attacker has control over the
information flow. Workflows can be manipulated, important data can be overwritten and much
more damage can be done if not prevented by additional security mechanisms.
Smart Products rely heavily on networks and data transfer. “Sniffing” data can be prevented by
low-level technical measures as e.g. protected transfer cables themselves. In the area of Smart
Products, this is not possible because devices may be mobile and wireless data transfer is used.
A solution is to encrypt and sign all sensible data before transferring it. This enables the
receiver to be sure that no attacker has received the data and also allows assuring that the data
is sent from the sender and has not been modified during transfer. A disadvantage of generally
encrypting all data is the high cost in terms of computational power. The sender as well as the
receiver has additional effort in encryption and decryption. Level-1 Smart Products may not be
able to apply secure encryption.
An alternative in some cases is local processing of sensible data. By not transferring large
packets of data but processing it locally, the amount of data that has to be encrypted can be
radically reduced. Imagine a system that uses fingerprint recognition for authentication. It
could either send the picture of a scanned finger to a second Smart Product which will extract
minutiae and compare them to a database of known fingerprint minutiae. Or the first device
could extract the minutiae locally and transfer only them (which means much less data) to the
second Smart Product. This results on lower computational effort for network communication

because less data has to be encrypted, transferred, and decrypted. In heterogeneous networks,
where different communication technologies are used and network traffic has to be converted
during transfer, this reduces the demands to all nodes but the initial sender.

3 Approach
3.1 Definition of security terms

In this Section, we define some key security terms that are going to be used throughout this
paper: confidentiality, integrity, authenticity and authorization.
3.1.1 Confidentiality
Confidentiality means that the assets of a computing system are accessible only by authorized
parties. Confidentiality is usually implemented using cryptographic algorithms.
3.1.2 Integrity
Integrity means that assets can be modified only by authorized parties or only in authorized
ways. Integrity is mostly implemented using one-way functions in combination with
cryptographic algorithms.
3.1.3 Authenticity
Authenticity means that an entity can prove who or what they claim to be. Authentication
services are usually implemented by a proof of knowledge, a proof of ownership, or a proof of
biometric trait.
3.1.4 Authorization
Authorization means that policies are used and enforced to specify access rights. Authorization
is implemented through access rules that are used by access control mechanisms to determine if
an entity is allowed to access information or not.
3.2 CIA, Authorization, and Smart Products

To achieve reliable and usable security, an analysis of existing security services in the context
of smart products and highly dynamic environments is needed first. This Section presents such
an analysis. In such a context, we show that confidentiality, integrity and authenticity can be
automated quite well, but authorization cannot.
3.2.1 Confidentiality
Confidentiality can be achieved using encryption to protect data. Here are symmetric, such as
AES, and asymmetric encryption mechanisms like RSA. Symmetric key encryption demands
the distribution of cryptographic keys among participating devices. Asymmetric key encryption
performs, in general, worse than symmetric key encryption. Hence, large chunks of data are
rarely encrypted using asymmetric keys, but only selected data, such as symmetric keys. In

smart products, the process of symmetric key distribution is a potential challenge because if a
unique key is demanded for every pair of communicating entities, the number of required keys
equals where is the total number of communicating devices.
Nonetheless, it is feasible to embed public-private key pairs into them. Such an approach is
sufficient in principle and implements confidentiality into high dynamic environments using
existing and standard cryptographic systems.
3.2.2 Integrity
Integrity has to assure that any unauthorized change of data is recognized. Data integrity is
usually accomplished using one-way hash functions and public key encryption or with just
symmetric keys. Message Authentication Codes (MAC) [Krawczyk-1997] are implemented
using symmetric keys and digital signatures [Rivest-1978] with public-private key pairs. Since
such cryptographic tools are expected to be embedded into smart products in the future (as seen
in Section 1), there are going to be enough cryptographic tools available for securing data
integrity.
3.2.3 Authentication
Authentication is required to obtain a proof of correctness over an identity claim. In smart
product scenarios there are basically three types of authentication: device-to-device, device-to-
user, and user-to-user. There are sufficient mechanisms based on digital certificates that can
carry out device-to-device authentication automatically. Device-to-user and user-to-user
authentication can also be realized using proofs of knowledge, biometric traits or digital tokens
together with public-key encryption. In such a case, after users authenticate themselves to
smart products, such devices might be used to automatize other authentication procedures
between users and other devices.
3.2.4 Authorization
Authorization is needed to specify access rights and enforce them. It is implemented through
access rules, and the collection of such rules is referred to as a rule set. There are mechanisms
that allow fully automated generation of rule sets for smart products. Such approaches,
however, disregard adaptivity to the end-user. The general problem is resulting from the
diversity of user preferences, so more information regarding the users is required.
Authorization problems regarding adaptivity and user in smart products are discussed in
Section 4, where the existing access control models are outlined and evaluated regarding their
suitability to smart product scenarios.

4 Reliable and Usable Authentication

Computer systems, which can be accessed by many persons, need some sort of security
mechanisms to prohibit collisions of different interests by different persons. The first step in
guaranteeing access rights to an entity (another computer, device, or a living being) is
identification. Identification is an unproved claim of the entity to be someone. The next step,
authentication, verifies this claim by providing a proof of the entity’s identity. Computer
systems generally map such a proved identity to an abstract “user” with specific rights.
The process of authentication, requires the entity to supply an authenticator which can be
something only the entity knows (e.g. a password or PIN), something only the entity has (e.g. a
smartcard), or something only the entity is (e.g. a fingerprint or iris scan).
Authentication services in the area of Smart Products have two important aspects to cover:
reliability and usability. Reliability aspects of authentication services target functional
compliance. They support successful authentication for the correctly-identified users and
dismissal of attackers with forged identities. Successful attacks are negligible – as is the
probability for false-positive authentication results. The aspect of usability covers the ease of
interaction for human entities. An impact from the complexity of authentication processes to
computers systems is non-existent and can be elided.
Usability influences security in the way that users which do not understand security measures
tend to work around them rendering the measures inefficient [Adams-1999].
The explanation generally is that the (authentication) process is too complex or too abstract for
the human user to understand.
Only authentication that is usable supports security. Reliability on the other hand is crucial for
security because an unreliable system guarantees no security.
A trade-off between usability and reliability for human users must be found. Ignoring one
aspect incriminates the whole system.
4.1 Related Work

Literature presents three ways to authenticate which are mentioned in section 3.2.3:
authentication by knowledge, by possession, and by biometrics (see Figure 1: Different
Methods of Authentication).

Authentication
Knowledge
“what you know/remember”
Possession
“what you have”
Biometry
“what you are/do”
Figure 1: Different Methods of Authentication
For device authentication, only authentication by knowledge is feasible, because there is no

such thing as possession or even unique biometrics traits for devices. Incorporating a
‘possessed’ entity for device authentication requires the device to communication somehow
with the entity. This process could be emulated which results in the situation that only the
information stored on the entity is relevant for authentication, not the possession of it.
Authentication of humans generally allows all three authentication methods.
4.1.1 Authentication by Knowledge

Proving an entity’s identity with knowledge requires a shared secret between the entity to
authenticate and the entity/device which checks the authentication proof. Ideally, the secret is
only known to the entity and can be verified without revealing it [Bellovin-1992].
The standard way to implement authentication by knowledge is that the entity identifies itself
to the target system which responds with a challenge. The challenge is to supply the shared
secret. Then, the target system compares this response to stored information (e.g. the secret
itself or a hash of it). If the comparison turns out positive, the authentication is successful. See
Figure 2: Standard Way to Implement Authentication by Knowledge for an overview.

Entity Device
Identification
Challenge
Response
Comparison with
stored information
Authentication
result
Figure 2: Standard Way to Implement Authentication by Knowledge
Karen Renaud separates authentication by knowledge into memometrics and cognometrics

[Renaud-2005]. Memometrics are shared secrets that an entity has to supply with or without a
cue. Cognometrics are shared secrets that must be recognized by the authenticating entity, e.g.
a position on a picture or a face5. We believe that memometrics and cognometrics are similar
and both require recalling of information. Therefore, we do not distinguish between them.
Table 2: Different Authentication by Knowledge Mechanisms presents some mechanisms for
authentication by knowledge and specific aspects of them.
Table 2: Different Authentication by Knowledge Mechanisms
Mechanism Secret Knowledge Particular Aspects

Password authentication A character string of variable Complex and long passwords
length with special characters are
hard to remember, Simple
and short passwords are easy
to guess
PIN authentication A string of digits of fixed Random numbers are hard to
length remember, short PINs can
5
Passfaces™http://www.realuser.com/ and Déjà Vu [Dhamija-2000]

easily be attacked by trying

all possible combinations
Passphrase authentication A sentence of words Similar to password
authentication, but often
easier to remember
Pattern authentication User has to draw a pattern on Residues from fingers can be
a touchscreen seen on the screen
Personal question User has to answer a Prone to social engineering
previously set question about
herself
Remember a position on a User has to select a Usability depends on the size
picture previously defined position of the area that has to be
on a picture (many pictures selected and the structure of
possible) the picture’s contents
A disadvantage of authentication by knowledge is that the secret may be retrieved by an

attacker without the attacked entity’s knowledge. Knowledge can be copied. This allows for
impersonation attacks and identity theft (see Section2.3). It depends on the quality of gathered
revision data if such an attack can be detected, prohibited, and pursued.
4.1.2 Authentication by Possession

Authenticating an entity by possession requires something that only the entity has control of.
The proof of authentication is the access to such a thing, for example a smartcard.
The standard way how authentication of entities by possession is implemented is shown in
Figure 3: Standard Way to Implement Authentication by Possession: The target system (which
checks the authentication) poses a challenge that can only be answered by using something that
knowingly only the identified entity has control of. The challenge might be to encrypt some
character string using a private key that is stored on a smartcard. The decryption can be
accomplished with the publicly available public key. The outcome of the authentication
depends on the entity responding with the correct answer to the posed challenge.

Entity Device
Identification
Challenge
Relay challenge to
possessed object
Response
Comparison with
stored information
Authentication
result
Figure 3: Standard Way to Implement Authentication by Possession
Table 3: Different Authentication by Possession presents some prominent mechanisms for

authentication by possession and specific aspects of them.
Table 3: Different Authentication by Possession
Mechanism Possessed Object Particular Aspects

Smartcard authentication Crypto processor with a Card can be stolen
stored private key
RFID authentication RFID transponder Proximity to reading device
may lead to unintentional
authentications
Barcode authentication Printed barcode that is read Barcode can be copied
by optical device
Mobile TAN One-way PIN is sent to Cellphone required
cellphone
chipTAN Information encoded in video chipTAN reader required

is scanned with special

device which displays a one-
way PIN
The main disadvantage of authentication by possession is that the possessed object could be
stolen. The advantage over authentication by knowledge is that the attacked entity can notice
the theft and initiate countermeasures, e.g. notifying an administrative instance about the theft.
An important aspect of the possessed thing is that it cannot easily be copied. This would reduce
the security to the level of authentication by knowledge. Lending an object to another person to
circumvent authentication processes temporarily is possible, but after the object has been
returned, the other person will not be able to authenticate again. Sharing a password is
permanent.
Another disadvantage in the earlier days of authentication by possession is the possessed
objects (for example SecurID6 tags by RSA Security) were expensive. Nowadays, there are
affordable solutions available. The Smart Products prototype implementation is able to
authenticate users by possession of RFID tags.
4.1.3 Authentication by Biometrics

A very usable way of authenticating a human entity is biometric traits. A biometric trait is a
unique attribute or feature of a human’s body. Commonly used traits are fingerprints, iris
recognition, eigenfaces, and DNA scans. Beneath those physiological traits exist behavioural
aspects which are used for biometric authentication: typing or walking style[Derawi-2010]and
voice attributes (high order cepstral moments) for example.
Authentication via biometric traits requires the following steps as displayed in Figure 4:
Standard Way to Implement Authentication by Biometrics. At first, the trait has to be measured
using special hardware for a physiological trait or a combination of hard- and software for
behavioural ones. In many cases, only parts of the recorded traits are used for authentication
purposes. Fingerprint recognition for example is solely based on so-called minutiae, points
where fingerprint lines run together. The positions of relatively few minutiae are enough to
recognize a person. After the extraction of the relevant parts, these are compared to stored
biometric information. For privacy reasons, the stored data may not be used to reconstruct the
original biometric information [Zhou-2009].
6
RSA SecurID, http://www.rsa.com/node.aspx?id=1156

Entity Device
Identification
Supply biometric
trait using special
hardware
Extract relevant
parts (and apply
helper scheme)
Comparison with
stored information
Authentication
result
Figure 4: Standard Way to Implement Authentication by Biometrics
Table 4: Different Authentication by Biometricspresents some biometric authentication

mechanisms and specific aspects of them.
Table 4: Different Authentication by Biometrics
Mechanism Biometric Trait Particular Aspects

Fingerprint authentication Minutiae (Distribution of Only ten fingers available per
fingerprint lines) human
Iris recognition Very detailed structure of the Only two irises available per
human iris human
Eigenface authentication Eigenvectors of human face Only one face available, can
pictures be forged with photograph
DNA nucleotid sequences (STR - Very few STRs are sufficient
short tandom repeats) are for unique identification,
extracted and compared extraction of traits complex

Biometric authentication has three major drawbacks compared to authentication by knowledge

or possession. Obviously, biometric authentication only works for human users and not for
devices. Secondly, if a user forgets her password, a new one can be created. This does not hold
for biometric treats. Humans generally only have ten different fingerprints. Revocation of
biometric authentication data is much more complex than for other types of authenticators. The
third drawback is privacy issues. Gathering biometric traits may reveal personal data about
illnesses or other aspects of the human which are bland for authentication. Such information
must be protected. On the other hand, theft of biometric traits is more challenging than stealing
an entity’s password or possession.
The Smart Products prototype implementation allows users to authenticate using their
fingerprints.
4.1.4 Multifactor Authentication

To increase reliability and therefore security, authentication mechanisms can be combined to
form multifactor authentication. This helps to maintain reliable authentication even if one of
the authentication mechanisms is successfully attacked. Requiring from an entity to pass all
authentication mechanisms increases reliability.
It is important to note that only authentication mechanisms of different factors (knowledge,
possession, biometric traits) should be combined to get the expected increased reliability.
Combining password authentication with the answer of a secret question is not multifactor
authentication because both authentication mechanisms are knowledge-based.
Popular examples for multifactor authentication are the GSM networks phone access strategy
and EC-cards for cashless payments. The GSM networks require participants to have a SIM
card (authentication by possession) and to know a PIN (authentication by knowledge). For
cashless payments, the banking institution gives out a smartcard (authentication by possession).
The payment process requires the salesperson to read the customer’s smartcard and the
customer to either enter a PIN number (authentication by knowledge) or sign with her name
(authentication by biometric trait).
Multifactor authentication increases reliability but reduces usability. The authentication process
is more complex and takes more time. For users who want to use a system, this increased
amount of time may be displeasing because they do not recognize the advantages: After
authentication, the system works the same way as it would have done with one-factor
authentication. For reasons similar to this, multifactor authentication should only be used in
environments which demand high security or in situations when the reasons and consequences
of multifactor authentication have been communicated to the users.

4.1.5 Taxonomy
Figure 5: A Taxonomy of Authentication Mechanisms presents a taxonomy of the three
authentication mechanisms as well as their most important aspects for reliability and usability.
Knowledge Possession Biometrics
Reliability aspects Reliability aspects Reliability aspects

• Secret can be • Object can be stolen • Revocation has
revealed/copied • Expensive objects problems
• Secret can be shared
Usability aspects Usability aspects Usability aspects

• Secret can be • Easy to use • Privacy can be
forgotten invaded
Figure 5: A Taxonomy of Authentication Mechanisms
4.2 Reliable Authentication

Reliability is the aspect of authentication that tries to prevent unauthorized system access. A
reliable authentication service – in opposition to an unreliable one – ‘guarantees’ correct
behaviour of the authentication service as e.g. in reducing falsely positive authentications to a
negligible fraction of all positive authentications.
The reliability of authentication mechanisms can be measured by taking the amount of false-
positive authentication results into account. A wrongly authenticated entity is only the reason
for a problem. The problem arises when the entity is granted with access rights based on the
(incorrect) proof for the entity’s identity. This problem can be approached by more reliable
authentication mechanisms, more reliable implementations of authentication mechanisms or at
later stages by applying behaviour deviation detection technologies.
4.2.1 Reliable Authentication Methods

One can formulate a general order for reliability of different authentication mechanisms.
Authentication by knowledge seems to be easier to attack than authentication by possession
because information can be retrieved by copying it. This way, the attacked entity does not

necessarily notice that her secret knowledge has been compromised. Possession used for
authentication cannot easily be copied. Furthermore, theft requires direct interaction with the
possessed object while knowledge can be retrieved by a spectrum of methods, like e.g. social
engineering or searching the whole search space (“brute force” attack). Authentication by
biometric traits has an even higher level of reliability because biometric traits are difficult to
steal, to copy or to forge. Even a “stolen” finger can be recognized by some fingerprint readers
which check the finger’s temperature.
It is to note that reliability depends heavily on how a specific authentication mechanism is
implemented. For example, if a fingerprint reader that simply takes pictures taken with a
camera is not as reliable as one that checks contour and body temperature. A complex
password may deliver higher security and reliability as the fingerprint reader presented first.
Preventing Design Flaws

All used mechanisms may suffer from design flaws which enable attackers to succeed much
more easily than by attacking the mechanism with brute force techniques.
The proprietary Cypto-1 stream cypher used by Philips on their MiFare Classic smartcards was
broken[Courtois-2008]. Attackers could copy such smartcards which were used for payment in
the London transport system and the Mensa at several universities. If Philips had used a
different non-proprietary algorithm, the probability that a design flaw such as the one in
Crypto-1 existed, would have been minimized.
The crypt() function was used for encryption on UNIX systems. Before the introduction of
glibc2, this function used only the first eight characters of the input string to generate the
cypher. All subsequent characters were ignored. This leads to the problem, that even a user
with a ‘secure’ password of adequate length and complexity had the security of a password
consisting only of the first eight characters. The search space for attackers was much smaller
than expected.
Flaws introduced during implementation

An authentication mechanism with good design may suffer from flaws introduced during the
implementation phase. Developers that write code for security-relevant modules but have
minor knowledge about security may write code that reduces security. Even good programmers
are not immune to making programming errors. The problem of implementation errors can be
handled by exhaustive testing and code-reviews.

In 2008, the Debian Security Team7 disclosed an error in the widely used SSL implementation
OpenSSL which rendered many cryptographic keys vulnerable. The vulnerability allowed the
forgery of certificates used for authentication.
Introducing Multifactor-Authentication to Increase Reliability

No software system is free from implementation errors, neither design aspects, nor
implementation problems.
To increase reliability with this in mind, the combination of different mechanisms increases
security when they are carefully selected. Authentication mechanisms from the same
authentication factors (authentication by knowledge, possession or biometric traits) may suffer
from similar problems. Because of that, it is recommended to combine different authentication
factors for “true” multifactor authentication as presented in Section 4.1.4.
4.3 Usable Authentication

The second important aspect of authentication in the area of Smart Products is usability of
authentication techniques.
Usability describes how efficient and easy a human entity can interact with a computer system.
Usable authentication in special is about the composition of the authentication process.
The human user has to understand the authentication interface and what actions in what order
are required to go through the authentication process. An authentication method is usable if the
user is as less bothered as possible while authenticating. This includes mainly, but not
exclusively, interaction time, interaction complexity and behavioural predictability.
4.3.1 Interaction Time

A usable authentication process bothers the user as less as possible. This means that the
timespan for interaction is as small as possible. The total interaction time is separated into the
time needed for supplying authentication information to the system and the time the system
takes to process this information. While the aspect of processing time gains less and less
importance because of faster hardware, the time for supplying information is important und
deviates by different authentication mechanisms.
Entering a password is usually done by using a keyboard or keypad. Proficient users are able to
use such devices fast and error-free. Thus, the time for entering a password, PIN or passphrase
as well as the user’s effort can be neglected. Scanning a fingerprint or iris requires some
practice but the needed time is similar to entering a password. Other biometric traits take much
more time until the required information is collected. Imagine an authentication system that
uses individual walking styles. It would require the user to walk around to provide the data.

Authentication by possession is difficult to examine in terms of time. Some possessed objects

may require no human interaction at all, as e.g. wireless communication with an RFID tag
worn by the user. Other objects like smartcards or objects with barcodes demand much more
time-taking action from the user. The objects must be taken out of storage and placed on a
reading device. Depending on the user’s behaviour, an object may be easily accessible or not,
e.g. on a key ring that the user always has with her.
4.3.2 Interaction Complexity

Complex interaction increases interaction time (see Section 4.3.1) and cognitive load of the
users. While there are groups of users with cognitive disabilities that hinder them to
accomplish complex processes, all kinds of users are distracted by such processes.
Authentication process designers always have to keep in mind that the users want to do their
work with the system, and do not focus on authentication itself.
Authentication by knowledge is commonly used and therefore known to most users. This kind
of authentication is less complex. Entering a password is a common task, but recognizing an
area of a picture and selecting it may be new to some users but easy to learn. Authentication by
possession is similar complex: an object has to be used, usually put on or brought in the near
proximity of a reading device. Biometric authentication is difficult and takes a role compared
to the one of authentication by possession in terms of interaction time. Entering a fingerprint by
pressing a finger on a reading device is easy. Scanning an iris is more complex: the user has to
look into a special camera lens and the eye has to be placed correctly. Designers should take
this into account and make the camera’s position as accessible as possible. No user wants to
kneel to authenticate her.
The main consequence of multifactor authentication is that it prolongs the authentication time
and increases authentication complexity. While this increases security as stated in Section 4.2,
this massively decreases usability. We recommend two-factor authentication as a limit for
combining authentication methods for general purpose applications. A good way to achieve
usable authentication under the assumption of multifactor authentication is to combine an
interactive authentication method (e.g. authentication by knowledge in the shape of password
input) with a non-interactive (e.g. wireless authentication by possession of a ME device). The
additional factor “authentication by possession” has no influence on usability but still increases
reliability.
All these aspects of complexity reduce the user’s acceptance for authentication mechanisms
and lead to situations where users bypass such mechanisms [Adams-1999].
4.3.3 Behavioural Predictability

Users focus on the business functionality of applications. In smart environments with many
devices, authentication is a distraction from the real task the users want to accomplish.

Authentication processes should be designed to have few impacts on user’s cognitive load and
therefore always act predictable.
This means that the authentication process is transparent: the outcome of authentication should
be displayed to user as soon as this information is available. Elements of the user interface
should behave as expected and work for the user.
A bad example for “correct” behaviour is the reset button in HTML form fields. When clicked,
it sets all fields of the associated form to their initial values. If authentication is included in a
greater process, as e.g. entering a new phone number and a combination of username and
password in a single form to reduce cognitive load, the reset button clears all entered
information. This is a problem when the user is not sure if she typed the correct password
characters (the password field displays bullets instead) and only wants to clear this particular
field.
Other examples of unpredictable behaviour are PIN input fields that are automatically
processed after the character maximum has been entered. A related problem arises from system
that requires additional steps before entering the authentication data. Imagine an electronic
cash system that first requires to user to enter her smartcard, then press “ok”, enter her PIN and
press “ok” again. The first press on “ok” seems unnecessary.
Usable authentication has to be easy to use, the user must always know (or at least have a slight
idea) what is expected from her and what happens next. Standard rules for usability taken from
human-computer-interaction research apply as well.

5 Reliable and Usable Access Control

Access Control (AC) mechanisms are well known from different domains. What landlords do
with keys and doors is similar to what a security administrator does with computer systems and
access policies. The doors and the access policies secure the resources behind them. But as
there are different ways to secure a house, there are different options for securing proactive
knowledge of smart products. The SmartProducts AC mechanism has to ensure that only
authorised entities are able to access proactive knowledge. For this purpose, owners and
manufacturers have to manually determine the confidentiality of all knowledge but security-
related data (e.g., access rules), which is per-se confidential. The AC will be applied to all
requests for proactive knowledge and will work as a filter – only authorised requests are
forwarded to the storage of proactive knowledge.
5.1 Related Work

This Section provides an overview of different access control models and provides an
evaluation of such models regarding their suitability to smart product scenarios. In this Section,
we describe the following AC models: Blacklists, Mandatory AC (MAC), Discretionary AC
(DAC), Role-Based AC (RBAC), and Attribute-Based AC (ABAC). This Section concludes
with a set of recommendations for an AC models suitable for smart product scenarios. It
concludes that ABAC models together with Blacklists are the most suitable solution for such
scenarios. The role of AC mechanisms, which are implemented according to AC models, is to
ensure that only authorized entities are able to access the information and functions of a
computer system (principle of authorization) [Stajano-2002].
5.1.1 Blacklist
A Blacklist AC is a very simple AC that blocks all requests from entities that are included in a
Blacklist. It is used to thwart known or recurrent attackers. Blacklists have to be configured
manually or, sometimes, they can be updated automatically according to predefined rules, e.g.,
multiple unauthorized requests, or a series of failed authentication procedures. Blacklists
usually outperform other AC mechanisms because their complexity class is lower than those,
and its performance can be O(1) in big O notation with a very small constant factor for the
blacklist lookup. Blacklists are a rather simple to use AC, but also rather inflexible, since there
no conditional access policies can be defined.

5.1.2 MAC / DAC

MAC and DAC are two early AC models [DoD-1985]. MAC and DAC can be seen as
complementary approaches, but both link access rights directly to the related entities.
In MAC, a central administrator controls the access rights of each entity of the system. No
other entity is able to change the access rights. In such a context, MultiLevel Security (MLS)
(such as Bell-La Padula [Bell-1976]) is an often used approach. In MLS, each entity or object
of the system has a security level given by a central authority. Each entity is only able to access
other entities or objects that have the same or a lower security levels. Mandatory Integrity
Control (MIC) is a similar approach and is used in Microsoft Windows Vista (and later).
Processes can only write or delete other objects with an security level lower or equal to their
own.
DAC differs from these approaches as each entity can hand its rights over to other entities.
That way, users are able to share objects among each other. DAC is used in UNIX and
Windows-based systems for sharing data and resources.
5.1.3 RBAC
RBAC [Ferraiolo-1992] introduced a new way by setting roles between the entity and the
related rights. That way, each entity can have several roles and each role can be held by
multiple entities. For administrative purposes, roles are established first, and afterwards they
are assigned to entities. Since roles usually rarely change, this reduces the complexity for
administrating RBAC significantly after the first setup. If only those entities change that inherit
a role, this can be simply addressed by adding or deleting entities (in form of the name or a
unique identifier) that are associated with the regarding role. Roles can change dynamically
and in that way the user might gain and lose roles automatically when doing special tasks.
5.1.4 ABAC
One of the newest models is ABAC [Yuan-2005]. ABAC uses attributes instead of roles to link
rights to entities. This procedure allows the use of dynamic conditions encoded in attributes,
such as the location of an entity, to decide whether to grant access or not. Since the role as well
as the security level of an entity can be seen as an attribute, it is possible to integrate concepts
known from other AC models like DAC or RBAC.
5.1.5 Hybrid approaches

In reality, the distinction between different AC models is not as strict as shown in this Section.
There are hybrid models like the Location-Aware Role-Based Access Control (LRBAC)
[Ray-2006], which allows the use of a geographical location as a “role”. It is often possible to
derive a less complex AC model from a more complex one, e.g., it is possible to create an
MAC mechanism from an ABAC model.

5.2 Reliable Access Control

As stated in [D4.1.1], a multi-layer approach is envisioned for achieving a high level of
security and privacy for smart products. This includes a blacklist as the first layer, access
control functionality as the second layer, and an intrusion detection concept as the final layer.
In addition to this vertical structure, also a horizontal structure of defence is envisioned to
make the layers even stronger against penetration of devices by an intruder. This is done
cooperatively by a set of trusted smart products. To determine the trustworthiness [Neisse-
2007] of smart products, all trusted nodes build up a virtual network, a so called Trusted
Network (TN).
In general two classes of TNs can be distinguished: First, TNs composed of devices that have
the same owner and second, TNs that are composed of devices of the same manufacturer. Thus,
every smart product participates in two TNs. TNs are strictly separated from each other, that
means, no confidential information is exchanged between TNs (i.e., no transitivity). The
manufacturer is e.g. not able to access the owner data and vice versa. Inside a single TN, smart
products can exchange confidential information like access rules (owner TN or manufacturer
TN), user profiles (owner TN), or manufacturer data (manufacturer TN). To realise the idea of
TNs, smart products of the same TN have a pre-shared secret. This pre-shared secret is sent to
every smart product after it is bought and activated for the first time. In this process, the user
has to verify that this new smart product is allowed to integrate itself into the owner’s TN. This
can be done manually, e.g., with out of bound communication [Statjano-2002] or automated
with the help of a ME. Overall, this is similar to the Resurrecting Duckling Model proposed by
[Statjano-2002].
5.2.1 Multilevel Access Control for Smart Products

Smart products are user adaptive devices which require AC mechanisms with maximum
flexibility since they are related to the everyday life of a heterogeneous set of end-users. Smart
products need to maintain user profiles that have attributes and values about users, such as
preferences to fulfil their tasks. ABAC models are an evident candidate for building up AC
mechanisms for smart products because they provide maximum flexibility in comparison to the
aforementioned AC models.

Figure 6: Theoretical comparison of different AC models.
ABAC models are, however, more complex than the other models listed in this Section. Such
complexity resultss in a larger consumption of computational resourcesresources than simpler
approaches. Resources on smart products are limited, thus,
hus, to reduce to costs of AC operations
a Blacklist AC mechanism can be executed before the ABAC mechanism. The Blacklist filters
out known misbehaving entities and their requests do not reach the ABAC mechanism. For
instance, after an entity, which was not blacklisted at first, has multiple identical requests
denied by the ABAC mechanism, such an entity can be temporarily or permanently added to
the blacklist.
AC mechanisms like ABAC are dynamic and flexible. However, they are also hard to
configure in the right way. While MAC and DAC have only one way to link access rights to
the user, RBAC and, especially, ABAC allow for different ways of binding access rights to
entities through indirect mapping. This flexibility enables very compact and meaningful policy
sets. However, if not correctly used, it can lead to a complex and incomprehensible set of rules.
This problem is very likely to occur
occur in case of inexperienced users. This is an important
challenge that is addressed with Interactive Rule Learning in Section 5.5..
The relation between flexibility of an AC mechanisms and the usability is shown in Figure 6.
This figure shows that MAC / DAC can be used by non-expert
non expert users but the number of needed
rules for non-trivial
trivial scenarios is extremely high. The figure also illustrates that RBAC and
ABAC can have very short rule sets, however, only expert users might be able to do so (since it

200
is difficult to manually define a minimal rule set for a complex scenario). If more rules are used
in RBAC and ABAC, it is possible to emulate MAC / DAC mechanisms with the difference
that always a role or an attribute is in between entities and their related access rights. Finally,
the figure shows that ABAC plus Interactive Rule Learning can be used to create reduced rule
sets even by non-expert users.
5.2.2 Cooperative Intrusion Detection

As described in [D4.1.3], redundancy is important to achieve high data availability. However,
for an attacker this reveals new possibilities to get access to confidential data. Since data is
stored on multiple devices, an attacker can simply attack the one with the weakest protection or
with a known vulnerability.
In particular, redundancy may lead to less strict access rules because every device that has to
store the data needs the corresponding rights. If an attacker is able to steal the identity of a
user/ device or to circumvent the authentication process in another way, she gets full access
rights of the user or infiltrated device. This is called an inner attack [Beckerle-2009a]. Under
these conditions, a traditional AC mechanism is not able to fend the intruder off. An intrusion
detection mechanism is needed. Different kinds of IDS can be distinguished. A non-exhaustive
list of existing IDS is shown in Figure 7. In the following, the different attributes of an IDS are
described according to [Debar-1999].

Figure 7: Different IDS [Debar-1999]
Detection Method
The method of detecting an intruder can be either behaviour- or knowledge-based. For
behaviour-based detection, a database with “normal” behaviour of all accessing entities is
needed as a basis for comparison. In case the behaviour of an entity differs from this “normal”
behaviour, it is classified as an attack. A knowledge-based IDS includes a database with known
attack signatures. If the behaviour of an entity has such a signature, it can be detected and
classified as an attack.
Behaviour on Detection
In case an IDS detects an attack two options exist. The IDS can simply activate an alert to
disclose the attack. The other option is to actively defend against the attack, e.g., by blocking
all future requests from the attacker.

Audit Source Location

The detection of an attack can take place on the attacked device (host-based) or on the network
infrastructure (network-based). While a host-based IDS analyses the behaviour, a network-
based IDS analyses network packets.
Usage Frequency
The intrusion detection can take place in real-time or periodically. For real-time monitoring, a
continuous analysis is required.
Conclusion
Since not all possible attacks are known for the diverse application scenarios of smart products,
only a behaviour-based IDS is feasible. An alert is not enough to protect users against attackers
because most inexperienced users do not know what to do if an attack takes place and
automated attacks occur very fast. For that reason, a continuous real-time monitoring is needed.
Only this way an active defence is possible. A network-based IDS needs some kind of router
between the devices. However, since smart products are connected in ad-hoc networks, a
network-based IDS is not applicable.
Most attackers will act in a way that is different from normal behaviour. Such “abnormal”
behaviour can be detected by anomaly detection [Vaccaro-1989]. The challenges thereby are
the limited resources of a smart product and the limited awareness that a single device has
about its environment. It can be difficult to determine which behaviour can be considered
normal and which behaviour can be considered as an anomaly.
For that reason, smart products will work together to cooperatively decide whether an attack
takes place. For this purpose, smart products of the same owner-TN share information about
entity behaviour, and monitor and compare the behaviour of every entity with earlier
behaviour. In addition, the potential type of attack is limited by the lower layer security
mechanisms (see Section 5.2). For example, as described above, DoS attacks are already
detected and prevented by the AC mechanism.
If, for example, the user Mr. Smith normally accesses his personal documents between 6am
and 10pm from the location “Brussels” and an access takes place at 3am from an entity
authenticated as Mr. Smith but from the location “China”, this is a potential security breach
and has to be further analysed. If a smart product of the same TN is able to track Mr. Smith in
another location like his bedroom, the cooperative decision of the smart products will be
“deny” for the access request from China. Furthermore they can inform Mr. Smith that his

authentication has been abused and that he should, e.g., use a better password in the future.
Again, it is important to ensure that authorised users are not hindered in performing their tasks.
A suitable (and potentially configurable) trade-off between security and usability is subject for
future research. Since time constraints it may not be possible to design and implement
cooperative intrusion detection in SmartProducts but since it is mostly independent it should be
possible to integrate it later without a huge amount of effort.
After defining a suitable AC model and a cooperative intrusion detection system for smart
products it is still fundamental to define how the rules for such AC model are generated. Such
rule generation should consider a set of requirements that are discussed in the next Section.
5.2.3 Usability
As described in Section 5.2.1 and 5.2.2, AC and cooperative intrusion detection provide a very
secure basis for protecting confidential data. However, one important question to answer is:
What is private and confidential data? The answer to this question cannot be stated clearly, it
depends on the person being asked. For that reason, it is important that the user’s preferences
are considered in the decision of what is made public and what has to be kept secret. However,
it cannot be expected that the user is satisfied by defining all these rules manually for every
device she is going to use [Cranor-2005]. There is a need for some kind of automation in such
a way that every user has to select his preferences only once and that this preferences are used
afterwards automatically with respect to his earlier decisions. In addition, a set of default rules
suitable for most use case enhances the usability of the security mechanism.
That way, the user’s intervention is merely required to generate the access rules. However,
there still may remain a lot of interaction requests if rules are too fine-grained or if there are
simply too many to handle them in a comfortable way. Appropriate rules should not only cover
the current context but also future situations such as for example "Any employee may use the
printer”. When new employees are hired, they directly have the right to use the printer. An
overly specific rule that does not generalise would be: "Mr. Jonson can use the printer”. Rules
of this kind would be necessary for each employee, leading to a hardly manageable set of rules.
Too general rules are problematic, too, because they may allow unauthorised entities to do
restricted tasks. If e.g. a rule says "Everyone is allowed to do anything" the AC itself
is needless.
A good set of rules for smart products should be specific enough to allow only authorised
entities to access confidential proactive knowledge while being as general as possible to
minimise the administration effort. Unfortunately, many users tend to define too fine-grained

or too general rules. The concept presented in section 5.5 represents a means of supporting the
user in defining appropriate access rules by applying an AI-supported rule
learning mechanism.
Another problematic point arises if user-defined rules are inconsistent and, consequently,
contradictory. Also, rules that become outdated over the years often remain in the system. A
huge number of required user interactions as well as unexpected behaviour of the AC
mechanism due to inconsistencies, old rules, and the actual amount of rules that arise over the
years, cause that most users become overwhelmed or irritated. In that case, users often tend to
either define overall rules such as “Everyone is allowed to do everything” or completely turn
off the AC mechanism. For that reason, a rule management tool is required that solves all of
the challenges listed above.
5.3 Formalization of access Rules

In this Section, formalizations for Entities, Objects, and Access Rules are presented. This
formalization will help later to define constraints in a formal way, that have to be solved for
usable and reliable security for smart products. Since this formalization focuses on security, it
is orthogonal do the conceptual framework presented in [D2.1.3].
5.3.1 General terms

System
System means an information system like a PC, a network of PCs, a smart Product, or a
network of smart Products. Access to restricted objects (see 5.3.3) of a system is only granted
if the accessing entities are authenticated.
Owner
The entity, that is the owner or responsible of a system.
Set Operator “/”

Set A / Set B defines the Set that has all elements of Set A that are not part of Set B.
Set Operator “∆”

Set A ∆ Set B defines the Set that has all elements that are part of Set A or Set B that are not
part of both, similar to the exclusive or operator in computer science.

5.3.2 Entities
All Entities
The Set of all entities in the world is called W
• All entities:
Entities in the system

The set of all entities in the system is called E.
• All entities in the system: | ⊆
Group
A group is a subset of entities in the system
• Group: | ⊆
Entity
An entity e is a person or a device which is able to access information or functionality of an
object in the system. This connoted that all e are authenticated to the system.
• Entity: | ∈
5.3.3 Objects
All Objects
The set of all objects in the world is called O
• All objects =
Objects in the system

The set of all objects in the system is called D
• All objects in the system: ⊆
Group of Objects
A group of Objects is a subset of objects in the system
• All objects in the system: ⊆
Object
An object is information, a function or a set of functions in the system
• Object: | ∈
5.3.4 Access- and Deny-Rules

Access allowed

Access allowed means that a single entity or a group is allowed to access an object. In the
following this is represented by the number 1.
• Access allowed: 1
Access denied
Access denied means that a single entity or a group is not allowed to access an object. In the
following this is represented by the number 0.
• Access denied: 0
Rule
A rule is a function that describes for a set of Entities E that they have (1) or do not have (0)
access to the object d.
Therefore we define a Set of relations that describes the space of all possible rule
relations in a system.
• : × ! → #, , ↦ , ∶= #
| ∈ , ∈ !, # ∈ (0,1)
• = ( × × # . : , → # | ∈ ! , ∈ !, # ∈ (0,1) )
A rule is the related function to one element of .
• + ∈
• ∀+ !∃. : × → #, , ↦ , ∶= #
| ∈ , ∈ , # ∈ (0,1)
Rule set
A rule set is a set of rules that describes the access rights for a system.
• /0 = ( ). ∀ , ∃ , . ∈ , ∈
5.3.5 Decision sets

Access and Deny Sets
The space of allow access decisions and deny access decisions.
• Allow Access Set:

o 123 = ( , | ∈ , ∈ . , = 1)
• Deny Access Set:
o 45 = ( , | ∈ , ∈ . , = 0)
User preferences
Describes the access decisions the owner wants.

• Set that describes which accesses the owner wants:

o 3104 = ( , | ( ∈ , ∈ ). 6 7 689: 8;; ::}
• Set that describes which accesses the owner do not want:
o 3104 = (( , ) | ( ∈ , ∈ ). 6 7 689: <}
5.4 Constraints for Access Control

In this Section, we define the requirements for AC rule sets for smart product scenarios taking
into account both security and usability constraints. Not all constraints presented in this Section
are orthogonal, thus conflicts do exist. Such conflicts are detailed and explained in the end of
this Section.
The security constraints for building up AC rule sets are regarding specific or permissive rules
and also the meaning of such rules. Each requirement is assigned a letter S followed by a
number.
The usability constraints for building up AC rule sets are regarding the existence of redundant
rules, their consistency and understandability, and also related to the total number of rules.
Each usability requirement is assigned a letter U followed by a number.
5.4.1 Reliability constraint S1: specific (permissive) rules.

Access rules have to be specific enough to leave no opening for intruders. Rules like “everyone
is allowed to do everything” render AC mechanisms useless in practice.
Formal:
Minimize (|123 / 3104 |)
5.4.2 Reliability constraint S2: meaningful rules.

Access rules have to reflect the expectations of the smart product owner. Rules like “every
employee of the university is allowed to use the printer” have a better semantic meaning than a
similar rule stating that “everyone with glasses is allowed to use the printer”, even if every
employee of the university wears glasses.
Formal:
Minimize (| 3104 ∆ 123 | + | 3104 ∆ 45 |) | ∀ . ∈

5.4.3 Usability constraint U1: no redundant rules.

Rules or set of rules that are fully covered by other rules or set of rules can be deleted without
changing the behaviour of the AC mechanism. Thus, if a rule set A is a subset of a rule set B,
then rule set A can be deleted. Redundant rules only increases the complexity of a rule set
without adding any security features and make such sets more confusing for the end user.
Formal:
∀ (?, @) → # ∈ /0 ∄ B (? B , @ B ) → # B ∈ /0.
? B ⊆ ? ∩ @ B ⊆ @ ∩ # = #′
5.4.4 Usability constraint U2: consistent rules.

Consistent rules mean that two or more different rules must not be contradictory. Contradictory
rules could lead to unpredictable access decisions or worsen the usability by unnecessarily
increasing the complexity of the rule set.
Formal:
∀( ∈ , ∈ ). ∀ ( , ) ∈ /0 ∄ B ( , ) ∈ /0.
( , ) ≠ B ( , )
5.4.5 Usability constraint U3: general, understandable and manageable rule sets.
AC rules need to be general enough for users to understand and manage.
Formal:
Minimize (| 3104 ∆ 123 | + | 3104 ∆ 45 | | ∀ . ∈
5.4.6 Usability constraint U4: minimum number of rules.

The number of rules that describes the scenario should be minimal to make the rule set
understandable and manageable.
Formal:
Minimize |/0 |

The use of general rules in requirement U3 contradicts the requirement S1 regarding specific
rules. Thus, the best compromises between specific and general rules need to be reached. The
best compromise is, however, connected to the user’s preferences and it is, therefore,
individual.
Rule U2 is not only a usability requirement, since it can also impact the security level obtained
by the AC mechanism. An inconsistent rule set can lead to a non- expected behaviour that can
compromise the security of the smart product.
In the next Section we develop a rule generation procedure that takes the aforementioned
requirements into account. Such procedure combines automatic rule generation with user
interaction.
5.5 Access Rule Generation

Nowadays, the common procedure for rule generation is to do it manually. Therefore, the
requirements listed in Section 5.4 need to be considered by the owner of the smart product. The
manual generation of rules by inexperienced users will likely result in misconfigured access
rule sets (or the manual deactivation of security mechanisms), which eventually end up into
security vulnerabilities. Therefore, the rule generation process should be automated as much as
possible. Learning algorithms, from the Artificial Intelligence research field, are able to
accomplish this goal [Carbonell-1983].
5.5.1 Automatic Rule Learning

Over the years, a variety of learning algorithms have been developed that try to imitate natural
learning or use a more technical approach as a starting point. Some approaches, such as the
multi-layer Perceptron [Riedmiller-1994] or the Boltzmann Perceptron Networks [Yair-1990],
try to reproduce the functioning of a brain at the level of neurons. Other mechanisms, such as
support vector machines [Schölkopf-1999] are based on a more abstract mathematical concept.
Existing algorithms further differ with respect to their applicability, speed, and accuracy [Jin-
2005, Haykin-2008].
Rule learners pursue in relation to the algorithms mentioned in the previous Section, a very
intuitive approach. They try to find causalities in recorded databases and express them in
simple rules. For example, in a database that describes the attributes of different animals like
ravens, sparrows and pigs such a rule could be as follows: "If an animal can fly and has
feathers, it is a bird". This approach has the particular advantage of being relatively easy to
understand for humans as opposed to for example the hyperplane of a support vector machine.

This is both a psychological and a practical advantage. From a psychological perspective,

because people tend to accept something more likely if they are able to understand it, and form
a practical point of view, as it is feasible to detect potential errors faster and as it is much easier
to add individual thoughts [Beckerle-2009].
Extracting knowledge out of data by using a rule-learning algorithm is a well-known topic.

However, for defining good access rules, a fully automated rule generation is unfortunately not
worth most of the time. It is very difficult to determine automatically what kind of information
needs to be protected. The whereabouts of a person, for instance: taxi drivers may have their
geographical position public available, but for lawyers or doctors on their way to clients or
patients must keep their location information strictly private.
It could be possible to decide which information should be public and private by analyzing the
user profile. Thus, automatic rule set generation is possible, but it is expected that errors would
also be a commonplace. However, if related information for automatic rule generation is
missing, automatic processes are not possible. Hence, the smart product owners have to decide
by their own regarding the access rules.
Therefore, a proper solution is to use automatic rule generation to create an initial rule set that
is later presented to the user. Interactive Rule Learning algorithms can generate a set of rule
sets and present them to users that decide which specific rule set suits best to their context. A
rule learner can be used to analyze the set of access rules of a smart product regarding the
actual behaviour of entities [Fürnkranz-1999].
Such an analysis disclose whether rules are shadowed, redundant, or correlative, and which
exceptions exist following the definition and classification presented in [Hamed-2006].
Furthermore, in interaction with users, the number of rules usability is minimized by analysing,
pruning, and rebuilding the set of access rules. This procedure is called Interactive Rule
Learning (IRL) [Beckerle-2009].
Combined with the ABAC, the IRL helps the user to build a secure and usable set of access
rules. The expected outcome of ABAC+IRL is shown in Figure XXX 3. This concept
represents an important step towards usable security. An automated rule learning algorithm can
fulfill the following requirements: S1, U1, U2 and U4. Users have to verify the compliance of
requirement S2, since it depends on the context and also on the smart product owner
preferences. To satisfy requirement U3, regarding general rules, interaction between the smart
product owner and the rule leaner is required.

5.5.2 Constrains Solving Algorithm

An algorithm that can solve the constraints U1, U2 and U4 in a manual generated rule set by
considering the hierarchical position of d is shown in Listing 1. The actual rules are first
extracted in a tree structure. Afterwards the new constrain free rules are read.
// Build the structure

∀ (d ∈ D) do {
// Insert all d as Nodes in a tree structure
pos = hierarchic position of d;
Insert d as Node into tree structure at position pos;
∀ (father nodes of Node at position pos) {
If (Node is a new leave of actual father node) do {
Number of leaves of actual father Node++;
}
}
∀ (e ∈ E) do {
// Add entities that have access to d
If (e has access to d) do {
∀ (father nodes of Node at position pos) do {
If e does not exist at father node {
Add e to actual father node;
}
Else {
at actual father node: e++;
}
If (leave was added) do {
Number of leaves of father Node++;
}
}
}
}
// Read the structure

∀ (nodes in tree structure) do {
∀ (e added to actual Node) do {
If (leaves of actual Node == e) do {

Add e to E’;
∀ (sub nodes of Node) do {
Delete e at actual sub node;
}
}
If (|E’| > 0) do {
Extract Rule (E’,d) -> 1 and add it to the new Rule set;
}
}
}
Listing 1 Constrains Solving Algorithm

6 Conclusion and Outlook

In this Deliverable it is shown that authentication and access control rule sets are the most
challenging aspect for combining usability and security in smart product scenarios. Other
security services, such as confidentiality and integrity can be automated and, therefore, made
fully transparent for end-users.
For authentication the concept of multi-level authentication is proposed. The combination of

mechanisms that are based on knowledge, possession, or biometrics guarantees reliability,
usability, and flexibility for authentication and therefore matches the smart products
requirements.
For access control, based on analysis of the different AC mechanisms, the combination of a
blacklist with an attribute based approach is proposed to fulfil todays and future needs for
adaptive devices. A series of security and usability constraints for access control rule sets are
listed. It is shown that the combination of automated rule learning with user interaction is able
to solve such constraints to a secure and usable system for smart products.
Future work will focus on the implementation and evaluation of these concepts in the smart
products platform.

Annex

A Requirements
The following table presents a mapping of the proposed concepts and the requirements investigated in [D4.1.1].
Table 5: Mapping of Concepts and Requirements
ID Requirement description Comment
Reliable and Usable
Reliable and Usable

Access Control
Authentication
SP.WP4.SEC.1 Smart products shall support fine-grained rights management x ABAC is a superset of IBAC and RBAC since an
mechanisms based on the identity (IBAC), role (RBAC) or mission attribute in ABAC can be a role as defined in RBAC or
(MBAC) of an entity. the identity as defined in IBAC
SP.WP4.SEC.2 Smart products shall support fine-grained rights management x ABAC supports fine-grained rights management
mechanisms regarding the granularity of data/ data structure.
SP.WP4.SEC.3 Smart products shall support fine-grained rights management x To secure the privacy a very versatile AC is used
mechanisms regarding privacy policies. combined with a beyond state of the art cooperative
intrusion detection
SP.WP4.SEC.4 There shall exist an identity management system. x The authentication and AC mechanisms and are able to
handle smart product IDs and biometric IDs

Reliable and Usable
Reliable and Usable

Access Control
Authentication
SP.WP4.SEC.5 Smart products should be able to cooperatively check the behaviour x The cooperative intrusion detection checks the
of other entities for harmful activities. behaviour of interacting entities and protects against
intruders
SP.WP4.SEC.6 Smart products should maintain a history of earlier interactions x The rule learning mechanisms will use a database which
which other products and users. stores the earlier behaviour of entities
SP.WP4.SEC.7 If malicious entities are detected, smart products should react in a x Both the AC and the IDS will react if misbehaviour if
proper manner such as restricting the rights of the entities or detected. One solution is blocking the entity via the
entirely removing them from the network. blacklist
SP.WP4.SEC.8 The owner of a smart product shall be the highest authority to x By using the IRL, users are
determine trustworthiness of other smart products. able to manipulate the security mechanisms
SP.WP4.SEC.9 Smart products should determine the trustworthiness of other smart x The AI mechanism of IDS and IRL will analyse and rate
products automatically by proactive information exchange. the trustworthiness of other entities
SP.WP4.SEC.10 Smart products should have the ability to encrypt and decrypt data Encryption is out of scope (see Section 2.2Fehler!
for communication. Verweisquelle konnte nicht gefunden werden.)
SP.WP4.SEC.11 Smart products should have the ability to encrypt and decrypt stored Encryption is out of scope (see Section Fehler!
data. Verweisquelle konnte nicht gefunden werden.)

Reliable and Usable
Reliable and Usable

Access Control
Authentication
SP.WP4.SEC.12 There shall exist authentication devices that provide user-related x For the biometric authentication of users there will be
security services. devices called Authentication Device.
SP.WP4.SEC.13 There shall exist authentication mechanisms for smart products in x Challenge Response combined with a pre-shared secret
order to enable reliable identification. on smart products is able to reliably identify smart
products
SP.WP4.SEC.14 Smart products shall detect unauthorized manipulations of proactive x The IDS is able to detect misbehaviour of any kind
knowledge for ensuring its integrity.
SP.WP4.SEC.15 Smart products should detect and try to avoid Denial-of-Service x The blacklist of the AC combined with the IDS is able
(DoS) attacks in a collaborative manner. to detect and potentially avoid DoS attacks
SP.WP4.SEC.16 Smart products should enable applications to prohibit certain x The AC is able to prohibit the distribution of proactive
proactive knowledge from being distributed among other peers. knowledge

B Glossary
Context Context characterizes the actual situation in which the application is
used. This situation is determined by information which
distinguishes the actual usage from others, in particular
characteristics of the user (her location, task at hand, etc) and
interfering physical or virtual objects (noise level, nearby resources,
etc). We thereby only refer to information as context that can
actually be processed by an application (relevant information), but
that is not mandatory for its normal functionality (auxiliary
information).
Environment An environment is an identifiable container with a clear border that
may contain smart products and other, non-smart product entities.
Entities inside the container can influence each other but they are
not influenced by anything outside the container.
Event Any phenomenon in the real world or any kind of state change
inside an information system can be an event. However, it must be
observable and some component in the information system must
observe it in order to notify parties interested in the event.
Lifecycle The lifecycle considered in the SmartProducts project consists of
the following four stages: Design, manufacturing, usage and
maintenance.
Proactive Knowledge The proactive knowledge of a smart product is defined as the
ensemble of data and formal knowledge representations, which
directly or indirectly facilitate its proactive behaviour.
Proactive behaviour in turn denotes mixed-initiative
communication, interaction, and action where the actual situation
and goals affect the turn-taking between a smart product and its
environment i.e. users and other smart products. In particular,
proactive knowledge may trigger human-product interaction and
product-environment communication based on perceived needs
(interaction needs may be ‘computed’ by the product as part of its
smartness, e.g., based on context changes).
Proactivity Proactivity is defined as a capability to initiate actions and exhibit
goal-driven behaviour without an explicit request or pre-defined
schedule.
Situation Situations are interpretations of context data. Thus, they can also

refer to the states of relevant entities.

Smart Products A smart product is an autonomous object designed for self-
organized embedding into different environments in the course of
its lifecycle, supporting natural and purposeful product-to-human
interaction. Smart products proactively approach the user,
leveraging sensing, input, and output capabilities of the
environment: they are self-aware and context-aware. The related
knowledge and functionality is shared by and distributed among
multiple smart products and emerges over time.
User A user of a smart product is a person who uses the functionality
and/ or the supporting tools of smart products. Thereby we
distinguish between smart products developers (end-users of the
SmartProducts platform, technically skilled), support service
workers (end-users of the SmartProducts platform, some technical
skills required) and smart products end-users (end-users of the
functionality provided by smart products, no technical skills
required) which differ in their level of expertise.

C List of Acronyms
ABAC Attribute Based Access Control

AC Access Control
DAC Discretionary Access Control
DNA Deoxyribonucleic Acid
DDOS Distributed-Denial-Of-Service
DoS Denial-of-Service
EC Electronic Cash or Eurocheque
GSM Global System for Mobile Communications
HTML Hyper Text Markup Language
IDS Intrusion Detection Systems
IRL Interactive Rule Learning
LRBAC Location-Aware Role-Based Access Control
MAC Mandatory Access Control
MBAC Mission Based Access Control
ME Minimal Entity
MIC Mandatory Integrity Control
MLS Multi-Level Security
PIN Personal Identification Number
RBAC Role Based Access Control
RFID Radio-Frequency Identification
TN Trusted Network
WP Work Package

References
[D1.2.1] D1.2.1 Initial Concepts for Smart Products. SmartProducts, 2009.
[D1.3.1] D1.3.1 Initial Concepts for Proactive Knowledge. SmartProducts, 2009.
[D2.1.3] D2.1.3 Final Version of the Conceptual Framework. SmartProducts, 2011.
[D2.4.1] D2.4.1 Initial Infrastructure for Semantic Data Management. SmartProducts, 2009.
[D4.1.1] D4.1.1 Requirements Analysis for Storing, Distributing, and Maintaining Proactive
Knowledge Securely. SmartProducts, 2009.
[D4.3.1] D4.3.1 Specification of Services to Manage Proactive Knowledge (preliminary

version). SmartProducts, 2009.
[D6.2.1] D6.2.1 Initial Architecture and Specification of Platform Core Services.

SmartProducts, 2009.
[D8.1.1] D8.1.1 Scenarios and Requirements for Smart Consumer Appliances. SmartProducts,
2009.
[D9.1.1] D9.1.1 Scenarios and Requirements for Vehicle Product Lifecycle Management
Application. SmartProducts, 2009.
[Adams-1999] Adams, A.; Sasse, M.: Users are Not the Enemy. In: Communications of the
ACM, Volume 42, Issue 12, 1999, 40-46.
[Aitenbichler-2003] Aitenbichler, E.; Mühlhäuser, M.: Audiobasierte Endgeräte für Ubiquitous

Computing und geeignete Infrastrukturen. In: Praxis der Wirtschaftsinformatik, 229:68–80,
2003.
[Beckerle-2009] Beckerle, M.: Interaktives Regellernen. Master Thesis, TU Darmstadt, 2009.

[Beckerle-2009a] Beckerle, M.: Towards Smart Security for Smart Products. In: AmI-
Blocks'09: 3rd European Workshop on Smart Products: Building Blocks of Ambient
Intelligence, Salzburg, 2008.
[Bell-1976] Bell, D. E.; LaPadula, L. J.: Secure Computer Systems: Unified Exposition and
Multics Interpretation. In: MTR-2997 Rev. 1, MITRE Corp., Bedford, Mass., March 1976.
[Bellovin-1992] Bellovin, S.; Merritt, M.: Encrypted Key Exchange: Password-Based

Protocols Secure Against Dictionary Attacks. In: IEEE Symposium on Security and Privacy,
1992, 72.
[Berghel-2000] Berghel, H.: Identity Theft, Social Security Numbers, and the Web. In:
Communications of the ACM, Volume 43, Issue 2, 2000, 17-21.
[Bimmel-2000] Bimmel, P.; Rampillon, U.; Meese, H.: Lernerautonomie und Lernstrategien.
Langenscheidt, 2000.
[Biskup-2008] Biskup, J.: Security in Computing Systems: Challenges, Approaches, and

Solutions. Springer-Verlag New York Inc, 2008.
[Carbonell-1983] Carbonell, J., Michalski R., Mitchell T.: An overview of machine learning.
Tioga Publishing Company, Palo Alto, 1983.
[Courtois-2008] Courtois, N.; Nohl, K.; O’Neil, S.: Algebraic Attacks on the Crypto-1 Stream
Cypher in MiFare Classic and Oyster Cards. In: IACR ePrint Archive: Report 2008/166, 2008.
[Cranor-2005] Cranor L.; Garfinkel, S.: Security and usability: Designing Secure Systems that
People can use. O’Reilly Media, Inc., 2005.
[Debar-1999] Debar, H.; Dacier, M.; Wespi A.: Towards a Taxonomy of Intrusion-Detection
Systems. In: Computer Networks, 31:805–822, 1999.
[Derawi-2010] Derawi, M.; Nickel, C.; Bours, P.; Busch, C.: Unobtrusive User-Authentication
on Mobile Phones using Biometric Gait Recognition. In: Sixth International Conference on
Intelligent Information Hiding and Multimedia Signal Processing, 2010.

[Dhamija-2000] Dhamija, R.; Perrig, A.: Déjà Vu: AUser Study Using Images for
Authentication. In: Proceedings of the 9th conference on USENIX Security Symposium –
Volume 9, 2000, 4.
[DoD-1985] DoD 5200.28-STD: United States Department of Defense, Trusted Computer,

System Evaluation Criteria (http://www.fas.org/irp/nsa/rainbow/std001.htm). 1985.
[Dolev-1983] Dolev, D.; Yao, A.: On the Security of Public Key Protocols. In: IEEE
Transactions on Information Theory, 1983, 198-208.
[Ferraiolo-1992] Ferraiolo, D.; Kuhn, R.: Role-Based Access Control. In: 15th NIST-NCSC
National Computer Security Conference, 554-563, 1992.
[Hamed-2006] Hamed, H.; Al-Shaer, E.: Taxonomy of Conflicts in Network Security Policies.
In: IEEE Communications Magazine, 44(3):134–141, March 2006.
[Haykin-2008] Haykin, S.: Neural Networks: A Comprehensive Foundation. Prentice Hall, 3rd
edition, 2008.
[Jin-2005] Jin, Y.: A Comprehensive Survey of Fitness Approximation in Evolutionary

Computation. In: Soft Computing-A Fusion of Foundations, Methodologies and Applications,
9(1):3–12, 2005.
[Mattern-2010] Mattern, F.; Floerkemeier, C.: Vom Internet der Computer zum Internet der
Dinge. In: Informatik-Spektrum, 33 (2), 2010
[Mirkovic-2004] Mirkovic, J.; Reiher, P.: A Taxonomy of DDoS attack and DDoS Defense
Mechanisms. In: ACM SIGCOMM Computer Communication Review, Volume 34, Issue 2,
2004, 39-53.
[Neisse-2007] Neisse, R.; Wegdam, M.; van Sinderen, M.; Lenzini, G.: Trust Management
Model and Architecture for Context-Aware Service Platforms. In Lecture Notes in Computer
Science, Springer Berlin / Heidelberg, 1803-1820, 2007.
[Pritchett-2008] Pritchett, D.: BASE: An Acid Alternative. In: Queue, 6 (3), 48-55, 2008.
[Ray-2006] Ray, I.; Kumar, M.; Yu, L.: LRBAC: A Location-Aware Role-Based Access
Control Model, In: Lecture Notes in Computer Science, Springer, 2006.

[Reding-2009] Reding, V.: What policies to make it happen? In The Future of the Internet - A
conference held under the Czech Presidency of the EU. Belgium: European Commission -
Information Society and Media, 2–5, 2009.
[Renaud-2005] Renaud, K.: Evaluating Authentication Mechanisms. In: Security and Usability
– Designing Secure Systems That People Can Use, 2005, 103-128.
[Riedmiller-1994] Riedmiller, M.: Advanced Supervised Learning in Multi-layer Perceptrons -

From Backpropagation to Adaptive Learning Algorithms. In: Computer Standards &
Interfaces, 16, 265-278, 1994.
[Schölkopf-1999] Schölkopf, B.; Burges, C. J. C.; Smola, A. J.: Introduction to support vector
learning. In: Advances in Kernel Methods: Support Vector Learning, 1-15, 1999.
[Schreiber-2008] Schreiber, D.; Hartmann M.: Association: Unobtrusively Creating Digital

Contracts with Smart Products. In: AmI-Blocks’08, 2008.
[Statjano-2002] Stajano, F.: Security for Ubiquitous Computing. John Wiley and Sons, 2002.
[Vaccaro-1989] Vaccaro, H.; Liepins, G.: Detection of Anomalous Computer Session Activity.
Technical report, 1989.
[Yair-1990] Yair, E.; Gersho, A.: The Bolzmann Perceptron Network: A Soft Classifier. In:
Neural Networks, 3:203-221, 1990.
[Yuan-2005] Yuan, E.; Tong, J.: Attributed Based Access Control (ABAC) for Web Services.
In: ICWS 2005 Proceedings, 2005.
[Zhou-2009] Zhou, X.; Wolthusen, D.; Busch, C.; Kuijper, A.: A Security Analysis of
Biometric Template Protection Schemes. In: Lecture Notes in Computer Science, Volume
5627, 2998, 429-438.


Smart Products

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Smart Products

Transféré par

Droits d'auteur :

Formats disponibles

SmartProducts

Proactive Knowledge for Smart Products

D4.2.2: Final Concept for Security and Privacy of

WP 4 – Storage & Distribution of

Deliverable Lead: TU Darmstadt

Delivery Date: 01.02.2011

Dissemination Level: Public

Copyright  SmartProducts Consortium 2009-2012

Name Organisation e-mail

Matthias Beckerle TU Darmstadt beckerle@tk.informatik.tu-darmstadt.de

Name Organisation e-mail

Matthias Beckerle TU Darmstadt beckerle@tk.informatik.tu-darmstadt.de

Name Organisation e-mail

Mathieu D'Aquin OU m.daquin@open.ac.uk

Pascale Hugues EADS pascale.hugues@eads.net

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 1

Section Status1 Old Section Description

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 2

LIST OF FIGURES ................................................................................................................................................ 5

LIST OF LISTINGS ............................................................................................................................................... 6

LIST OF TABLES .................................................................................................................................................. 7

EXECUTIVE SUMMARY .................................................................................................................................... 8

2 GOALS AND CHALLENGES ..................................................................................................................... 11

2.1 GOALS .................................................................................................................................................. 11

3.1 DEFINITION OF SECURITY TERMS .......................................................................................................... 16

4 RELIABLE AND USABLE AUTHENTICATION .................................................................................... 18

4.1 RELATED WORK ................................................................................................................................... 18

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 3

4.3 USABLE AUTHENTICATION ................................................................................................................... 28

5 RELIABLE AND USABLE ACCESS CONTROL .................................................................................... 31

5.1 RELATED WORK ................................................................................................................................... 31

6 CONCLUSION AND OUTLOOK ............................................................................................................... 47

C LIST OF ACRONYMS ................................................................................................................................. 54

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 4

Figure 1: Different Methods of Authentication .......................................................................... 19

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 5

Listing 1 Constrains Solving Algorithm .................................................................................... 46

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 6

Table 1: Revision chart in relation to [D4.2.1]............................................................................. 2

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 7

The idea of multi-level authentication is to combine authentication based on knowledge,

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 8

The administration of secure features in computational systems by non-expert end-users is

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 9

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 10

2 Goals and Challenges

2.1.1 Reliable Security

2.1.2 Usable Security

2.1.3 Reliable versus Usable Security

2.2 Focus of SmartProducts Security

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 11

As pointed out in [D4.1.1], access control is fundamental to realise privacy. Furthermore, it is

2.3 Attacks on Smart Products

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 12

2.3.1 Identity theft

A common countermeasure against identity theft is to harden authentication procedures.

2.3.2 Denial-of-Service (DoS) attacks

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 13

2.3.3 Sniffing network traffic

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 14

SmartProducts_D_4_2_2_Final Dissemination Level: Public Page 15

3.1 Definition of security terms

3.2 CIA, Authorization, and Smart Products