Visit ebookball.

com to download the full version and

explore more ebook or textbook

Applied Cyber Security and the Smart Grid:

Implementing Security Controls Into the Modern
Power Infrastructure 1st Edition by Eric Knapp,
Raj Samani ISBN 1597499989 9781597499989
_____ Click the link below to download _____
https://ebookball.com/product/applied-cyber-security-and-
the-smart-grid-implementing-security-controls-into-the-
modern-power-infrastructure-1st-edition-by-eric-knapp-raj-
samani-isbn-1597499989-9781597499989-17060/

Explore and download more ebook or textbook at ebookball.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Applied Cyber Security and the Smart Grid Implementing

Security Controls Into the Modern Power Infrastructure 1st
Edition by Eric Knapp, Raj Samani ISBN 1597499989
9781597499989
https://ebookball.com/product/applied-cyber-security-and-the-smart-
grid-implementing-security-controls-into-the-modern-power-
infrastructure-1st-edition-by-eric-knapp-raj-samani-
isbn-1597499989-9781597499989-17070/

Applied Cyber Security and the Smart Grid: Implementing

Security Controls Into the Modern Power Infrastructure 1st
Edition by Eric Knapp, Raj Samani ISBN 1597499989
9781597499989
https://ebookball.com/product/applied-cyber-security-and-the-smart-
grid-implementing-security-controls-into-the-modern-power-
infrastructure-1st-edition-by-eric-knapp-raj-samani-
isbn-1597499989-9781597499989-17038/

Cyber security and Global Information Assurance 1st

edition by Kenneth Knapp 1605663271 9781605663272

https://ebookball.com/product/cyber-security-and-global-information-
assurance-1st-edition-by-kenneth-knapp-1605663271-9781605663272-20184/

Cyber Physical Security Protecting Critical Infrastructure

at the State and Local Level 1st Edition by Robert Clark,
Simon Hakim ISBN 9783319328249 3319328247
https://ebookball.com/product/cyber-physical-security-protecting-
critical-infrastructure-at-the-state-and-local-level-1st-edition-by-
robert-clark-simon-hakim-isbn-9783319328249-3319328247-15774/
Cyber Physical Security Protecting Critical Infrastructure
at the State and Local Level 1st edition by Robert Clark,
Simon Hakim ISBN 3319328247 9783319328249
https://ebookball.com/product/cyber-physical-security-protecting-
critical-infrastructure-at-the-state-and-local-level-1st-edition-by-
robert-clark-simon-hakim-isbn-3319328247-9783319328249-17008/

The NICE Cyber Security Framework Cyber Security

Intelligence and Analytics 1st Edition by Izzat Alsmadi
ISBN 3030023605 9783030023607
https://ebookball.com/product/the-nice-cyber-security-framework-cyber-
security-intelligence-and-analytics-1st-edition-by-izzat-alsmadi-
isbn-3030023605-9783030023607-15840/

Cyber Physical Security Protecting Critical Infrastructure

at the State and Local Level 1st Edition by Robert M
Clark, Simon Hakim ISBN 3319328247 9783319328249
https://ebookball.com/product/cyber-physical-security-protecting-
critical-infrastructure-at-the-state-and-local-level-1st-edition-by-
robert-m-clark-simon-hakim-isbn-3319328247-9783319328249-15836/

Auditing Information and Cyber Security Governance A

Controls Based Approach 1st edition by Robert Davis
1000416127 9781000416121
https://ebookball.com/product/auditing-information-and-cyber-security-
governance-a-controls-based-approach-1st-edition-by-robert-
davis-1000416127-9781000416121-20148/

Cyber Security and Critical Infrastructure 1st edition by

Leandros Maglaras, Helge Janicke, Mohamed Amine Ferrag
9783036548463
https://ebookball.com/product/cyber-security-and-critical-
infrastructure-1st-edition-by-leandros-maglaras-helge-janicke-mohamed-
amine-ferrag-9783036548463-20056/
Kristin Haltinner · Dilshani Sarathchandra
Jim Alves-Foss · Kevin Chang
Daniel Conte de Leon · Jia Song (Eds.)

Communications in Computer and Information Science 589

Cyber Security
Second International Symposium, CSS 2015
Coeur d'Alene, ID, USA, April 7–8, 2015
Revised Selected Papers

123
Communications
in Computer and Information Science 589
Commenced Publication in 2007
Founding and Former Series Editors:
Alfredo Cuzzocrea, Dominik Ślęzak, and Xiaokang Yang

Editorial Board
Simone Diniz Junqueira Barbosa
Pontifical Catholic University of Rio de Janeiro (PUC-Rio),
Rio de Janeiro, Brazil
Phoebe Chen
La Trobe University, Melbourne, Australia
Xiaoyong Du
Renmin University of China, Beijing, China
Joaquim Filipe
Polytechnic Institute of Setúbal, Setúbal, Portugal
Orhun Kara
TÜBİTAK BİLGEM and Middle East Technical University, Ankara, Turkey
Igor Kotenko
St. Petersburg Institute for Informatics and Automation of the Russian
Academy of Sciences, St. Petersburg, Russia
Ting Liu
Harbin Institute of Technology (HIT), Harbin, China
Krishna M. Sivalingam
Indian Institute of Technology Madras, Chennai, India
Takashi Washio
Osaka University, Osaka, Japan
More information about this series at http://www.springer.com/series/7899
Kristin Haltinner Dilshani Sarathchandra
•

Jim Alves-Foss Kevin Chang

•

Daniel Conte de Leon Jia Song (Eds.)

•

Cyber Security
Second International Symposium, CSS 2015
Coeur d’Alene, ID, USA, April 7–8, 2015
Revised Selected Papers

123
Editors
Kristin Haltinner Kevin Chang
University of Idaho University of Idaho
Moscow, ID Moscow, ID
USA USA
Dilshani Sarathchandra Daniel Conte de Leon
University of Idaho University of Idaho
Moscow, ID Moscow, ID
USA USA
Jim Alves-Foss Jia Song
University of Idaho University of Idaho
Moscow, ID Moscow, ID
USA USA

ISSN 1865-0929 ISSN 1865-0937 (electronic)

Communications in Computer and Information Science
ISBN 978-3-319-28312-8 ISBN 978-3-319-28313-5 (eBook)
DOI 10.1007/978-3-319-28313-5

Library of Congress Control Number: 2015958547

© Springer International Publishing Switzerland 2016

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, express or implied, with respect to the material contained herein or for any errors or
omissions that may have been made.

Printed on acid-free paper

This Springer imprint is published by SpringerNature

The registered company is Springer International Publishing AG Switzerland
 Preface

The 2015 Cybersecurity Symposium: Your Security, Your Future was the second in a
series of conferences hosted by the Center for Secure and Dependable Systems
(CSDS). The symposium offered a key opportunity for academic researchers and
system stakeholders from industry and government organizations to meet and discuss
state-of-the-art and state-of-the-practice techniques and processes related to cyberse-
curity. The objective of the symposium was to provide a platform for stakeholders to
collaborate and exchange ideas and processes to help improve the security of today’s
critical systems. The 2015 Cybersecurity Symposium was partially funded by the State
of Idaho and CSDS.
Since its inception in 2014, the symposium has attracted national and international
stakeholders, including engineers, practitioners, researchers, and learners from indus-
try, government, and academia. The 2015 conference brought together approximately
50 attendees from diverse locations such as the US East and West Coast and Europe.
Hence, the opportunities created by this symposium to bring world-class knowledge
and state and nationwide interest to the ongoing efforts in cybersecurity by the
University of Idaho and the State of Idaho are significant.
The 2015 conference received 20 extended abstracts and 11 full-paper submissions.
The peer-review process for extended abstracts and research papers included two
stages. In the first stage, all potential participants submitted extended abstracts. These
abstracts were reviewed by the Organizing Committee. Authors of extended abstracts
deemed suitable for the conference goals were invited to present their research at the
symposium and to submit full papers for consideration for the conference proceedings.
In the second stage, full-paper submissions went through a series of anonymous
peer-reviews. The resulting detailed reviews were given to all draft authors. Decisions
about final paper acceptance were reviewed and approved by the Organizing Com-
mittee. The committee accepted nine papers to be included in the 2015 proceedings.
The collection of papers in these proceedings reflect four areas of scholarly work:
(1) permissions and trust evaluation, implementation, and management; (2) cloud and
device security and privacy; (3) social implications of networked and mobile appli-
cations, and (4) system and process assessments for improved cybersecurity. These
areas demonstrate a maturity in the fields of cybersecurity and privacy by providing
novel examples of secure computer systems and associated theoretical advances.
The results and case studies presented in these proceedings capture the scope of
current knowledge as well as potential future applications. Previous books on cyber-
security and privacy have been largely divided by discipline. Industry has discovered
the limitations to current security measures, social scientists have investigated public
attitudes and behavior toward privacy and security, engineers have investigated risks of
cybersecurity breaches in critical infrastructures, and computer scientists have explored
practical measures that can be taken to maximize online security while maintaining
some level of privacy for users. Until recently, these fields have operated in a
VI Preface

non-collaborative fashion resulting in a limited understanding of how technology

development and adoption are affected by broader societal needs.
The present proceeding are an attempt at merging the knowledge and strengths of a
number of different fields. Because we have included scholarly and professional work
from the social sciences, computer science, engineering, and infrastructure, this volume
provides a comprehensive and practical information source for graduate students,
faculty, industry, governmental organizations, and other stakeholders who are inter-
ested cybersecurity and privacy.
The careful selection and organization of the papers in this volume extends the fields
of cybersecurity and privacy in several important ways. The Cybersecurity Symposium
and resulting conference proceedings:
• Provide a platform for industry and academia to merge their knowledge and
experience
• Present a clear analysis of the challenges faced by the public and private sector
while simultaneously connecting these issues with current, cutting-edge, computer
science research
• Bring human factors into the analysis of cybersecurity and privacy concerns
• Present an avenue for social scientists and computer scientists to deepen their
understanding of security needs and privacy demands
• Include an analysis of the problems and opportunities in cybersecurity as it applies
to critical infrastructures
• Present an analysis of the economic impacts of cybersecurity
We look forward to this publication bridging cybersecurity advances in academia,
industry, and governmental organizations and providing a foundation to future
developments in the fields of cybersecurity and privacy.

October 2015 Kristin Haltinner

Dilshani Sarathchandra
Jim Alves-Foss
Kevin Chang
Daniel Conte de Leon
Jia Song
 Organization

The 2015 Cybersecurity Symposium was organized by the Center for Secure and
Dependable Systems of the University of Idaho. The center is partly sponsored by the
Idaho Global Entrepreneurial Mission. The conference was held at the Coeur d’Alene
Resort.

Programme Committee and Local Organizing Committee

Jim Alves-Foss University of Idaho, Secure and Dependable Systems, USA
Kevin Chang University of Idaho, Department of Civil Engineering, USA
Daniel Conte de University of Idaho, Secure and Dependable Systems, USA
Leon
Arvilla Daffin University of Idaho, Secure and Dependable Systems, USA
Kristin Haltinner University of Idaho, Department of Sociology and
Anthropology, USA
Jia Song University of Idaho, Secure and Dependable Systems, USA
 Contents

Permissions and Trust Evaluation, Implementation, and Management

Expanding RTEMS to a Multiuser System by Using Security Tags . . . . . . . . 3

Jia Song and Jim Alves-Foss

UI Tags: Confidentiality in Office Open XML . . . . . . . . . . . . . . . . . . . . . . 19

Lawrence Kerr

The Search for Trust Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

David E. Ott, Claire Vishik, David Grawrock, and Anand Rajan

Cloud and Device Security and Privacy

Surrender Your Devices or Be Turned Away: Privacy Rights at the Border. . . 49

Elizabeth J. Etherington

Comparing Encrypted Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Jim Buffenbarger

Social Implications of Networked and Mobile Applications

Can I Live? College Student Perceptions of Risks, Security, and Privacy in

Online Spaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Kristin Haltinner, Dilshani Sarathchandra, and Nicole Lichtenberg

How the Secure Use of Technology Could Influence Travel to and from
School for Elementary School-Aged Children . . . . . . . . . . . . . . . . . . . . . . . 82
Kevin Chang, Kristin Haltinner, and Reilly Scott

System and Process Assessments for Improved Cybersecurity

An Assessment Model and Methodology for National Security Systems. . . . . 107

Jennifer Guild

Security in Agile Development: Pedagogic Lessons from an Undergraduate

Software Engineering Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
J. Todd McDonald, Tyler H. Trigg, Clifton E. Roberts,
and Blake J. Darden

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Permissions and Trust Evaluation,
Implementation, and Management
 Expanding RTEMS to a Multiuser System
by Using Security Tags

Jia Song(B) and Jim Alves-Foss

University of Idaho, Moscow, ID 83844, USA

{jsong,jimaf}@uidaho.edu

Abstract. This paper discusses a research project that develops

enhanced security protections for operating systems running on secu-
rity enhanced microprocessors. Security tagging schemes are promising
mechanisms for enhancing the security of computer systems. The idea
of tagging schemes is to attach metadata tags to memory and registers
to carry information about the data being tagged. This paper summa-
rizes the features of these new microprocessors and discusses the use of
these features in the design of enhanced operating system security for an
exemplary real time operating system.

1 Security Tagging Schemes

Computers play an increasingly important role in modern life and it is now
widely recognized that people need to pay more attention to computer security
issues. Over the years, researchers and developers have devised various tech-
niques including encryption, firewalls, and virus scanners to provide secure com-
puting environments. The idea of enhancing these mechanisms by using hardware
to provide security features for operating systems and user applications is not
new. Decades ago researchers proposed techniques to add security labels (tags)
at the hardware level to help with the enforcement of system security proper-
ties [1,3]. Unfortunately, these techniques required more computing resources
and memory than was feasible at the time. As hardware speeds have improved,
the idea of security tagging has resurfaced as a promising mechanism for enhanc-
ing security.
Security tagging schemes attach labels to memory and/or registers to carry
information about data during program execution. These labels are also called
tags. They have been used by researchers to ensure that the semantics of com-
putations are correctly implemented; to isolate code and data, users and system;
and to enforce security policies at the hardware level. The implementation of
tagging in hardware provides developers with enhanced security mechanisms
without a penalty on performance, as compared to traditional microprocessors.
Therefore, tagging schemes are seen as promising mechanisms to help processors
and OSs (Operating Systems) implement security properly.
Security tagging schemes are known as promising mechanisms for enhancing
the security of computer systems. Security tagging was first designed and imple-
mented to protect against some low-level attacks, such as buffer overflow and

c Springer International Publishing Switzerland 2016
K. Haltinner et al. (Eds.): CSS 2015, CCIS 589, pp. 3–18, 2016.
DOI: 10.1007/978-3-319-28313-5 1
4 J. Song and J. Alves-Foss

format string attacks [6,7,12,14]. Recently, security tagging schemes have been
improved to prevent high-level attacks, which include SQL (Structured Query
Language) injection and cross-site scripting [2,4]. Tags are also implemented in
some specific architectures to support memory access control [8,9,13,15]. The
details of the comparison of these tagging schemes can be found in another paper
of the authors [11].
As part of the University of Idaho’s (UI) UITags research project, a tagging
scheme has been developed to secure RTEMS (Real-Time Executive for Multi-
processor Systems). In the UI tagging scheme, a 32-bit tag is associated with
every 32-bit memory and registers. The tag consists of three fields: Owner field,
Code-space field and Control-bits field. These fields provide information about
who owns the data, who can manipulate the data and other information for
further control the tagged data. During system execution, tags are checked and
propagated appropriately. Different from traditional operating systems, RTEMS
can be decomposed into many smaller components. Each component provides a
set of unique services to support the running of the system. Based on the func-
tionality and importance of the component, tags are associated with the code to
represent security levels. Furthermore, tagging rules were implemented to help
control the information flows in the RTEMS.
The original version of RTEMS implements a single-user multi-threaded model
of execution. To expand it to a multiuser system, the concepts of “superuser”
and “non-privileged user” were used. A superuser is a user who has authority to
create, delete, and control non-privileged users. Non-privileged users are isolated
from each other and can only control themselves, but have no abilities to create,
delete or control other users. By assigning different user tags to the data/code of
the system and user application, the data and code can be seen as belonging to
a specific user. Based on the tag, the system knows the specific permissions that
the code/data have, and therefore protects its resources from being accessed by
non-authority users. We expanded RTEMS from a single user system to multiuser
system, implementing a user manager module to handle the multiuser issues. This
paper briefly reviews the overall UI security tagging scheme, provides details of the
implementation of tags for multiple users and how the system code was changed
to support the advanced security tagging scheme for multiuser RTEMS system.
Future work is also proposed at the end of the paper.

2 RTEMS
RTEMS [5] consists of a super core (SCORE) and 18 managers. The 18 managers
provide different services and the SCORE provides kernel functions that support
the managers. After examining the code of RTEMS, we found that it has very
little security built in. Therefore, the UI tagging scheme has been developed with
the purpose to secure the RTEMS.

2.1 RTEMS Architecture

The original 18 managers of RTEMS provide services to user code in support
of concepts such as tasks, memory, timers, and communications. Each manager
 Expanding RTEMS to a Multiuser System by Using Security Tags 5

provides a well-defined set of services through directives that take the place of
traditional system calls. Each manager also has internal functions that it uses to
support implementation, some of these are private to the specific manager, and
some are intended to be used by other managers. In either case, these manager
internal functions are not intended to be used by user code.
In addition to each manager, RTEMS has a set of modules that make up
the SCORE subsystem. The SCORE provides services for all managers, and all
managers interact with the SCORE via directives. Some major SCORE modules
are: object, thread, chain, interrupt service routine (ISR), error handler, heap
and protected heap, workspace, initialization, message, time, watch dog, and
user extension. These modules are key to the internal working of RTEMS, but
are not intended for use by user code.
Conceptually the APIs are meant to be externally accessible, internally
restricted to other RTEMS modules or internal to specific modules. However,
RTEMS currently does not restrict access to any of these functions or their pri-
vate data structures. The following sections outline the major security concerns
that need to be addressed to secure RTEMS.

2.2 Security Concerns in RTEMS

The examination of RTEMS’s source code reveals several major security

concerns.

No Separation Between User and System. In RTEMS, there is no sep-

aration between user resources and system resources. In traditional operating
systems, the system has ultimate privileges while the user has limited privileges.
In RTEMS, both the user and system have ultimate privileges. Currently user
code can use all of the SCORE code, internal functions, and directives. This
means that the user can do everything that the RTEMS system can. For exam-
ple, the user has privileges to change the system configuration, delete system
tasks, etc. This is a design decision since RTEMS is intended for embedded
systems and is built for high performance. Unfortunately, this limits the use of
RTEMS in secure environments or from safely running untrusted code.

System has no Protection from Users. RTEMS has no protection from

users and no concept of multiple users. Take the directive, rtems task delete,
as an example. There is no check of the identity of the caller of this directive.
This means that other system managers can use this directive, other system code
can use it, and even users can delete any task by calling this directive. There is
no restriction on who can delete which task, which means that users could even
delete system threads.

No Separation of RTEMS Code. There is no isolation among RTEMS man-

agers, directives and SCORE. In RTEMS, SCORE works as the micro kernel of
6 J. Song and J. Alves-Foss

the system. If the SCORE code is misused by a user or attacked by a mali-

cious user, critical security problems may occur. Therefore it is important that
SCORE code be separated from other system code and user code.
RTEMS has 18 managers and each manager has its own functionality. Each
manager has specific directives that support the manager. RTEMS has internal
functions that help RTEMS managers function correctly, inline routines that
speed up the running of RTEMS, and library functions supporting some of the
functionalities. In the current version of RTEMS, every directive of a RTEMS
module can call any function, including internal functions of other RTEMS mod-
ules. This may cause security problems if any application in user code is modified
by an attacker, because the attacked code can use any other RTEMS code that
the attacker wants. With a Security Tagged Architecture (STA), mechanisms
can be implemented in RTEMS to prevent unintended or malicious usage of
manager and SCORE code.

No Separation of Different Users. Although RTEMS has a single user multi-

threaded model of execution, it can be expanded to be a multiuser system. To
be extended to a multiuser system, the system must have a method to identify
the owner of user data and keep it separated from other users’ data. However,
RTEMS cannot tell which user is the owner of specific user data. For a thread, it
might be a thread generated by user 1, a thread generated by user 2, or a system
thread. Since the owner of the thread is unknown, who has the permission to
change or delete it can not be specified. Currently RTEMS is a single user system
that contains no rules to specify who can do what. This becomes a problem when
RTEMS is extended to allow more than one user.

3 UI Security Tagging Scheme

3.1 Tag Format and Its Composition

As shown in Fig. 1, the tag is a 32-bit tag which consists of three fields:
Owner, Code-space, and Control-bits. The tag can be written as (Owner,
Code − space, Control − bits). In a tag, each of the Owner and Code-space
fields is represented with 12 bits, with the remaining 8 bits for the Control-bits.

Owner Field. In the implemented tagging scheme, the first field, the Owner
field, helps separate system code/data and user code/data. It indicates the
identity of the owner of the data or code. The values of the Owner field
can be classified into six major classes: SCORE internal, SCORE, Manager
internal, Manager, Startup and User. The SCORE internal class can be
further divided into three groups: SCORE internal init, SCORE internal
private and SCORE internal. The Manager internal class is also broken
into three groups: Manager internal init, Manager internal private and
Manager internal.
 Expanding RTEMS to a Multiuser System by Using Security Tags 7

Fig. 1. Tag format

By using the Owner field, the owner of data or code can be easily
identified. For example, the first field in the tag (object, Code − space,
Control − bits) indicates that the data or code associated with this tag is
object code or object data; where object is one of the SCORE modules. A
tag (task manager, Code − space, Control − bits) shows that the data
or code is owned by the task manager. In the remaining sections, SCORE in
the tag means this field could be one of the possible values in the SCORE class,
and the same holds for the Startup class, SCORE internal class, Manager class,
Manager internal class and User class. Although RTEMS currently only sup-
ports a single user, it is expanded to a multiuser system as part of this paper
(see Sect. 4). Therefore, multiple users are listed in the possible values of the
User class. Having different users for the Owner field ensures that a user can
only access its own data and code, but not other users’ resources.

Code-Space Field. The second field of the tag is the Code-space field. This
field shows which code space should manage the data or code. In addition to
this, the Code-space field is also critical for information flow control and mem-
ory access control. The possible values of the Code-space field are the same as
the Owner field. The Code-space can be User, Manager, Manager internal,
SCORE, SCORE internal and Startup. For example, the tag (User1,
Manager1, Control − bits) means the data are created in manager1’s code
for user1. Manager1 is used as a place holder for a specific manager name, such
as task manager, partition manager, etc.
Code-space is used to show the class of the code or data and helps con-
trol function calls. Users in the system should only use the manager directives,
and not directly use SCORE, SCORE internal, and Manager internal functions.
Therefore, firstly, Code-space is used to indicate which class the code belongs to,
and then rules can be provided to control which classes of code can use which
other classes of code.

Control-Bits Field. The Control-bits field is used for further control. It starts
with a single copy bit (bit 7) which indicates whether a return value has been
modified. The copy bit allows user code to have a copy of a trusted data value
8 J. Song and J. Alves-Foss

Table 1. Possible values of the memory type

Memory type Read or read/write

Data memory (x00) 000 read-only
100 - read/write
Stack memory (x01) 001 read-only
101 - read/write
Code memory (executable) 010 read-only
not entry point (x10) 110 - read/write
Code memory (executable) 011 read-only
entry point (x11) 111 - read/write

(i.e., a task ID) as long as it is not changed. The notation cp means the copy bit
is not set while cp indicates the copy bit is set. The return value to a user will
be tagged with the security class of the directive and will have the copy bit set.
If the copy bit remains set, this means that the user has not made any change
to the value. If the copy bit is not set, the data is treated as modified data and
will not be accepted when used as a parameter to a directive. This allows user
programs to store copies of system IDs and handles while maintaining security
of the values. For example, if user1 uses directive code from the task manager
to get a tag identifier, the directive returns an identifier tagged (user1, task
manager, cp). If the user modifies this returned ID, the tag will be changed to
(user1, user1, cp) to indicate this ID has been changed; and the OS will no
longer trust the ID. This allows the system to trust IDs that come from users
without having to keep an internal table of indirect identifiers or separate tables
for each user, and thereby improve performance and simplify system code.
Three of the control bits (bits 6 to 4) are allocated for memory type. To
further protect data in memory, memory is divided into three classes: stack
memory, code memory, and data memory. These three bits specify the memory
type, such as readable, writable, read-only, executable, entry point, data memory,
and stack memory.
– Stack Memory. Stack memory is readable and writable, and is treated using
register expression rules for stores, instead of assignment rules.
– Code Memory. Code memory stores the executable and readable code. The
“entry point” of a function has a special tag with it to indicate the correct
starting address for executing a function.
– Data Memory. All other memory is data memory which is readable and
writable, and it is treated using assignment rules.
The possible values of the memory type are shown in Table 1.
A world-readable bit (bit 3) is used to indicate that the tagged data can be
read by all entities; It can be used when the system (higher level) wants to give
the user (lower level) permission to access some data, such as configuration data.
The other 3 bits (bits 2 to 0) are reserved for future use.
 Expanding RTEMS to a Multiuser System by Using Security Tags 9

3.2 Tag Representation

In a tag, each of the Owner and Code-space fields is represented with 12 bits,
with the remaining 8 bits for the Control-bits. For Owner field and Code-space
field, the higher 4 of the 12 bits are used to indicate if the tagged data or code
is a system resource or not. If the higher 4 bits are 1111, this means that the
tagged data or code is from the system, otherwise it is from users. For system
code (tags that start with 1111), the lower eight bits are used to divide the code
into smaller classes. Among the 8 lower bits, the higher 3 bits indicate the level of
the class, and the lower 5 bits represent which component. For example, the level
of class includes SCORE internal class, SCORE private internal class, SCORE
internal init class, SCORE external class, manager internal class, manager pri-
vate internal class, manager internal init class, manager external class. The 5
bits which represent the component of the RTEMS can be a specific manager
or SCORE, such as task manager, partition manager, SCORE thread, SCORE
interrupt service routine and etc.
For the user code and data, all of 12 bits of the Owner field or Code-space
field are used to represent a user. When expanding the system to a multiuser
system, the 12 bits are further divided to support multiple users (see Sect. 4).

3.3 Lattice
Since the Owner field and Code-space field are used to define the security class
of the data, the ideas similar to those of the Data Mark Machine (DMM) [3]
can be implemented to control the information flows within RTEMS. The solu-
tion is a bit different from DMM since a hierarchy is defined for confidentiality
and integrity controls, and it is not for traditional multi-level security. However,
accesses still can be controlled to prevent “lower-level” entities from unautho-
rized access to higher level entities.
The lattice model of information flow deals with channels of information flow
and policies. For the lattice model of information flow, there exists a lattice with
a finite set of security classes and a partial ordering between the classes. The
nodes of the lattice represent the individual security classes. The notation ≤
denotes the partial ordering relation between two classes of information. For
example, A ≤ B means class A is at a lower or equal level than class B. The
notation ⊕ denotes the least upper bound (LUB) operation.
In a lattice, there exists a unique class C = A ⊕ B such that:

A ≤ C and B ≤ C, and
A ≤ D and B ≤ D implies C ≤ D for all D in the lattice.

The security class of an entity in the model, a, will be denoted as a, and it can
be written as a = (Owner(a), Code − space(a)). The Control-bits are ignored in
this discussion since they are used separately from the lattice-based controls
and formulas. Owner(a) refers to just the Owner field of a’s tag, Code-space(a)
refers to the Code-space field of the tag of a.
The definition of the LUB, ⊕, of the security classes of two tags is:
10 J. Song and J. Alves-Foss

If a = (Owner(a), Code-space(a)), and b = (Owner(b), Code-space(b)),

then a ⊕ b = (Owner(a) ⊕ Owner(b), Code − space(a) ⊕ Code − space(b)).

The definition of the equality of the security classes of two tags is:

If a = (Owner(a), Code-space(a)), and b = (Owner(b), Code-space(b)),

then if Owner(a) = Owner(b) and Code − space(a) = Code − space(b), then
the security class of a and b are the same.

The definition of the domination of the security classes of two tags is:

If a = (Owner(a), Code-space(a)), and b = (Owner(b), Code-space(b)),

then if Owner(a) ⊆ Owner(b) and Code − space(a) ⊆ Code − space(b), then
the security class of a dominates the security class of b.

The similar rules for ≤, <, ≥ and > operations can be defined similarly and
are not shown here.

3.4 Tagging Rules for the Basic Values in C

At the start of the system, and as each subroutine is called, data and code tags
are initialized with the correct security classification and memory types. This
section discusses how those classifications can be used, in the context of the C
programming language, to define tagging rules needed to satisfy the security
concerns based on the partial ordering and lattice concepts.
This section introduces the basic concepts of using tags at the C language
level. The full details can be found in the corresponding literature [10].

– During execution of a program, the tag of the current running thread is the
same as the security class of the program counter, denoted as PC.
– The tag of the variable a is the tag of the memory location of a and its security
class is denoted a.
– The tag of a literal, or constant, n, is the same as the tag of the PC. This is
because the use of the literal is controlled by the current thread.
– The security class of the tag of an array item, a[i] is the least upper bound
of the security class of the index to the array and the security class of the
memory location referenced by the array: a[i] = i ⊕ [[a + i]] where [[a+i]]
denotes the memory address referenced by a[i]. In cases where the copy bit
of the memory location is set, the tag of that memory location is used instead
of the LUB.
– The tag of a value referenced by a pointer, *p or structure p->fld or p.fld
is the tag of the memory location referenced. For example, ∗p = [[p]] where
[[p]] denotes the memory address referenced by the pointer p.
– All code will be tagged as read-only, executable memory, and all entry points
to functions will be tagged as function entry points (to avoid problems with
the misuse of function pointers).
– All data memory will be tagged as read-write data memory.
 Expanding RTEMS to a Multiuser System by Using Security Tags 11

3.5 Tag Manager and Tag Engine

To support the UI tagging scheme, a tag manager has been added to RTEMS to
allow the OS to handle the tagging issue, for example checking if the copy bit is
set or not in some specific functions and take or release the ownership of some
data. These tag checking and propagation can not be done at the hardware level
easily. Some tagging functions have been inserted into special RTEMS functions
to satisfy special requirements of the tagging scheme, such as setting the copy
bit of the ID’s tag that is going to be returned from some RTEMS functions.
The tag engine has been implemented at the hardware level to support the
tagging scheme. The tag engine can be turned on and off to test the whole
tagging system. Tag engine rules have been applied to different instructions.
Therefore when executing an instruction, the tag engine rules for the specific
instruction will be checked to ensure the instruction is allowed to be executed
based on the tagging rules. If that is not the case, the tag engine will generate
an error message and terminate the program.

4 Security Tagging Scheme for Multiuser System

To expand RTEMS to support multiple users, a new “user” construct has been
added to RTEMS, similar to the task construct. To manage the users, the con-
cepts of “superuser” and “non-privileged user” have been defined. All control is
managed through a new user manager.

4.1 Implementation of the Multiple User System

Before our work, RTEMS implemented a single-user multi-threaded model of

execution. To expand it to a multiuser system, the concepts of “non-privileged
user” and “superuser” have to be supported. A superuser is a user who has
authority to create, delete, and control non-privileged users. Non-privileged users
are isolated from each other and can only control themselves, but have no abilities
to create, delete or control other users.
The new RTEMS user model allows for 117 non-privileged user IDs and one
superuser. Each user can have up to 32 separated task IDs. To have more control
over users and their tasks, a set of task IDs is provided to each user. This allows
additional secure isolation between the tasks within a single user. To implement
this, the user levels’ Owner field of the tag is divided into two parts – users
and tasks. The higher 7 bits among the 12 bits are used to represent separate
user IDs and the lower 5 bits are used to indicate task IDs for those users. For
example, the 12 bits for the superuser are 1110 110 XXXXX, where the 1110
110 indicates superuser ID and the XXXXX represents task IDs. Since only 7
bits are used to represent different users, this limits the number of users in the
system to be user1 to user117 (0000 001 XXXXX to 1110 101 XXXXX), recalling
that 1111 XXX XXXXX is reserved for RTEMS code. Including the superuser,
there are 118 possible users in the system. For an embedded system, 118 users
12 J. Song and J. Alves-Foss

Table 2. New bit representation for Owner field of USER and LOW levels

USER 1110 111 11111

Superuser 1110 110 XXXXX
user117 1110 101 XXXXX
... ...
user2 0000 010 XXXXX
user1 0000 001 XXXXX
LOW 0000 000 00000

each with 32 possible subtasks should be sufficient. The implementation of 118

users does not influence the levels above the general user (USER) level, because
separate controls are made for users and their tasks. The new bit representation
for Owner field of tags are shown in Table 2.

4.2 User Manager

To change RTEMS to a multiuser system, system code needs to be modified
to support multiple users. This includes adding a user manager to RTEMS to
handle the superuser and its abilities to create, delete and control non-privileged
users and corresponding changes to the tag manager. In addition, the simulator
needed modification of the tag engine code to support the user hierarchy rules.
The user manager is supported by several user manager directives, such as
rtems user create directive, rtems user manager initialization directive
and rtems user delete directive, etc.
Take the rtems user create directive as an example, this directive checks
the caller of the directive and creates a non-privileged user. It first checks
that the calling user is the superuser, because only the superuser is autho-
rized to create, control and delete the non-privileged users. If this is the case,
rtems user allocate gets the next available user id, starting at 1, and updates
its internal data structures. After getting the user number, the get user tag
is called to get a specific tag associated with the task ids and task names for
that user. For example, if user number is 1, then a tag (USER1, USER1, true |
READWRITE | DATA MEMORY | WORLD NOT READABLE) is returned. If user num-
ber is 2, the function get user tag will return a tag, (USER2, USER2, true |
READWRITE | DATA MEMORY | WORLD NOT READABLE). Further in the function,
rtems tag word is used to tag the task ids and task names. (Although tags
are associated with pointers, they are actually being attached to the memory
location referenced by the pointer.)
In multiuser RTEMS, a user program is assigned a primary application with
task id 0. This is the first application to execute for the user. The primary
application for a user first declares an array of task id and another array of
task name. When creating a task, the user application passes two pointers to the
rtems task create directive which point to the task id and task name. Then
the directive creates the task for the user application and returns a system-wide
 Expanding RTEMS to a Multiuser System by Using Security Tags 13

unique task id back. By using the system task id, the user application is able
to start, suspend, resume, or delete the task.

4.3 Multiuser Example

The multiuser example starts from an Init function. The Init function first
uses the rtems user create function twice to create two non-privileged users.
In this example the PC’s tag is manually set to the SUPERUSER. Normally
this will happen in the kernel prior to calling Init. The result of calling the
rtems user create function is shown in Fig. 2. The Task id[1] to Task id[4]
are tagged with user1’s tag, and Task id[5] to Task id[7] are tagged with
user2’s tag.
Then the user application sends Task id[1] to Task id[4] to the direc-
tive, rtems task create, to create four new tasks separately. The directive
then creates four tasks and stores the RTEMS task ids into the Task id[1] to
Task id[4] respectively. The copy bit of the tags associated with Task id[1]
to Task id[4] will be set. Similarly, another three tasks will be created by user2
for Task id[5] to Task id[7].
The four tasks created for user1 are different from the three tasks for user2.
User1’s tasks keep printing out the time every five seconds. After starting user2’s
tasks, the tasks are suspended for 15 s and then wake up to attempt to delete
user1’s tasks.
The seven tasks run concurrently. Figure 3 shows output of the tasks running
without the tag engine turned on. At the first 15 s, tasks 1 to 4 are running and
printing time information every five seconds. After 15 s, task 5 starts to delete
task 1, task 6 deletes task 3 and task 7 deletes task 4. After successful deletion
of these tasks, only task 2 is still alive and running.
The output of running the seven tasks is displayed in Fig. 4. With tag engine
turned on, when user2’s task (task 5) wants to delete user1’s task (task 1), the
tag engine generates an exception, prints an error message and stops the system.

Fig. 2. Result of a successful call of user create function

14 J. Song and J. Alves-Foss

Fig. 3. User2 delete user1’s task without tag engine turned on

Fig. 4. User2 delete user1’s task with tag engine turned on

 Expanding RTEMS to a Multiuser System by Using Security Tags 15

From the information given by the tag engine, the call is successfully made and
the new PC’s tag is generated correctly ((USER2, TASK EXTERNAL, false |
READWRITE | DATA MEMORY | WORLD NOT READABLE)). However the exception is
raised on a LD instruction that the Owner field of the PC’s tag (USER2) does not
dominate the Owner field of the address’s tag (USER1). This is because when
task 5 tries to delete task 1, it uses the rtems task delete directive and passes
Task id[1] to it. Then, rtems task delete directive tries to get the specific
thread by using Task id[1], which is tagged with user1’s tag, and therefore
generates a LD error message.
Although RTEMS is not fully tagged and the tag engine has to be turned
on manually in the code, the test case shows that the UI tagging scheme for
multiple users is working and can be used to help isolate tasks of different users.

5 Conclusion and Future Work

This paper introduces a design of a new security tagging scheme that enhances
access control through least privilege while enabling good system performance.
The UI tagging scheme focused on securing RTEMS, a single user, multi-thread
model runtime executive. An evaluation of the RTEMS architecture provided a
better understanding of what tags can and cannot do. According to the security
enhancements that were needed, the tag was designed with three fields: Owner
field, Code-space field, and Control-bits field. By using these tags, the system
is able to separate RTEMS (i.e., code and data) and user (i.e., code and data),
divide RTEMS code into different levels, prevent users from using critical system
functions, and protect return values. The combination of Owner field and Code-
space field tags represents the security class of the tagged data. With the security
classes, lattice, and security rules, the information flow can be controlled in
RTEMS.
Modifications of RTEMS source code have also been made to support the tag-
ging scheme. This includes addition of a tag manager which provides tag checking
and propagation that can not be done in hardware. Some tagging functions have
been inserted into specific RTEMS functions to satisfy special requirements of
the tagging scheme, such as setting the copy bit of the ID’s tag that is going to
be returned from some RTEMS functions. RTEMS has also been expanded from
a single user multi-threaded model of execution to a multiuser system. RTEMS
now supports the concepts of non-privileged user and superuser, where the supe-
ruser has the authority to create, delete, and control non-privileged users. A user
manager has been added into RTEMS to support the tagging scheme for multiple
users.

5.1 Future Work

This section summarizes the future work that could be conducted as an extension
of the security tagging project.
16 J. Song and J. Alves-Foss

Fully Tag RTEMS Code to Enable RTEMS to Always use Tagging.

Currently, all of the test cases work by enabling and disabling tagging as needed.
Therefore only some of the RTEMS code is tagged. For future work, all of the
RTEMS functions have to be tagged, including libraries. The goal is to have a
tagged RTEMS running from the beginning of system initialization. In addition
to the RTEMS functions, global variables need to be tagged with care. This
is especially true when RTEMS is modified to a multiuser system. Some global
variables can be shared among different users while other global variables cannot,
due to the possibility that they may affect other users or the system. Therefore
these global variables need to be made usable only by a specific user manager.
In addition, the C library functions need to be considered and properly
tagged. Because of time restrictions, not all of the C library functions that are
used by RTEMS can be tagged manually. Therefore software tools will have to
be used to generate a list of the C library functions that are used in the RTEMS
benchmarks. These functions will be given special tags. By doing this, additional
checks will be applied when using these functions, to prevent malicious usage of
the important functions.
The process of tagging the complete RTEMS may be time consuming,
because RTEMS requires a fresh build and installation even with a small change
of the code, which takes around 20 min.

Reduce the Overhead of the Tagging System. Since almost every instruc-
tion execution requires tag checking of the source or destination operands’ tag,
it increases the overhead of the system. For example, normally, the LD instruc-
tion loads values from memory space to registers, but in the UI tagging scheme,
the LD instruction has to check the value’s tag and store it as the register’s tag
additionally. To minimize the overhead, tags can be cached as many as possible
to speed up the tag checking operations. Another way that could reduce the
overhead of the tagging system is to use a tag compression scheme, and data
and code spatial locality information to reduce the overhead.

Persistent Tags and User-Defined Tagging Rules. The current tagging

model focuses on the protection of code and data from unauthorized access
and modification. It is a first step toward enhanced security tagging, such as
user-defined tags. The support of user-defined tags may require the support
of persistent tags (tags that are maintained between system resets), that may
also be used for multi-processor (or multi-core) execution models and storage of
objects in file systems or other permanent storage.
In addition, the UI tagging scheme only supports fixed tagging rules. In the
future, it would be desirable to have user-defined tagging rules. Another manager
could be implemented to support user-defined tagging rules. However, to be able
to support user-defined tagging rules, the system should provide not only the
interface for users, but protections for the system in case a user tries to do
something that could violate the security of the system.
 Expanding RTEMS to a Multiuser System by Using Security Tags 17

Port Sample Applications to Evaluate the Performance of the Tag-

ging Scheme. Some sample applications could be ported to RTEMS. These
benchmark applications could help evaluate the performance of the UI tagging
scheme. This may require additional changes in RTEMS code. For example, the
portions of RTEMS and C libraries that are needed by the benchmark applica-
tions would need to be tagged. What’s more, RTEMS is only compatible with a
few applications and none of them are usable for evaluation purposes. Additional
efforts are needed to port applications to RTEMS. Based on evaluation results,
new methods for improving performance, may be proposed.

References
1. Burroughs Corporation, Detroit 32, Michigan. The Operational Characteristics of
the Processors for the Burroughs B5000, revision a, 5000–21005 edn. (1962)
2. Dalton, M., Kannan, H., Kozyrakis, C.: Raksha: a flexible information flow archi-
tecture for software security. In: Proceedings of the 34th Annual International
Symposium on Computer Architecture, vol. 35, pp. 482–493, May 2007
3. Fenton, J.S.: Memoryless subsystems. Comput. J. 17(2), 143–147 (1974)
4. Kannan, H., Dalton, M., Kozyrakis, C.: Decoupling dynamic information flow
tracking with a dedicated coprocessor. In: Proceedings of the 2009 IEEE/IFIP
International Conference on Dependable Systems and Networks, pp. 105–114.
IEEE, Estoril, Lisbon, Portugal (2009)
5. On-Line Applications Research Corporation. RTEMS C User’s Guide, edition
4.10.1, for rtems 4.10.1 edn., July 2011
6. Qin, F., Wang, C., Li, Z., Kim, H.-S., Zhou, Y., Wu, Y.: LIFT: a low-overhead
practical information flow tracking system for detecting security attacks. In: Pro-
ceedings of the 39th Annual IEEE/ACM International Symposium on Microarchi-
tecture (MICRO-39 2006), pp. 135–148. IEEE Computer Society (2006)
7. Shioya, R., Kim, D., Horio, K., Goshima, M., Sakai, S.: Low-overhead architecture
for security tag. In: Proceedings of the 15th IEEE Pacific Rim International Sympo-
sium on Dependable Computing, pp. 135–142. IEEE Computer Society, Shanghai,
China (2009)
8. Shriraman, A., Dwarkadas, S.: Sentry: light-weight auxiliary memory access con-
trol. In: Proceedings of the 37th International Symposium on Computer Archi-
tecture (37th ISCA’10), pp. 407–418. ACM SIGARCH, Saint-Malo, France, June
2010
9. Shrobe, H., DeHon, A., Knight, T.: Trust-management, intrusion tolerance,
accountability, and reconstitution architecture (TIARA). Technical report, AFRL
Technical Report AFRL-RI-RS-TR-2009-271, December 2009
10. Song, J.: Development and evaluation of a security tagging scheme for a real-time
zero operating system kernel. Master thesis, University of Idaho, May 2012
11. Song, J., Alves-Foss, J.: Security tagging for a zero-kernel operating system. In:
Proceedings of the 46th Hawaii International Conference on System Sciences
(HICSS), pp. 5049–5058, Wailea, HI, USA, January 2013
12. Suh, G.E., Lee, J.W., Zhang, D., Devadas, S.: Secure program execution via
dynamic information flow tracking. In: Proceedings of the 11th International Con-
ference on Architectural Support for Programming Languages and Operating Sys-
tems, pp. 85–96, Boston, MA, USA, November 2004
18 J. Song and J. Alves-Foss

13. Witchel, E., Cates, J., Asanovic, K.: Mondrian memory protection. In: Proceedings
of the 10th International Conference on Architectural Support for Programming
Languages and Operating Systems, pp. 304–316 (2002)
14. Yong, S.H., Horwitz, S.: Protecting C programs from attacks via invalid pointer
dereferences. In: Proceedings of the 11th ACM SIGSOFT Symposium on Foun-
dations of Software Engineering 2003 held jointly with 9th European Software
Engineering Conference. ACM, pp. 307–316, Helsinki, Finland, September 2003
15. Zeldovich, N., Kannan, H., Dalton, M., Kozyrakis, C.: Hardware enforcement of
application security policies using tagged memory. In: Draves, R., van Renesse, R.
(eds.) Proceedings of the 8th USENIX Symposium on Operating Systems Design
and Implementation, pp. 225–240. USENIX Association, San Diego (2008)
 UI Tags: Confidentiality in Office Open XML

Lawrence Kerr ✉
( )

University of Idaho, Moscow, ID, USA

[email protected]

Abstract. Maintaining confidentiality of data is critical, particularly in need-to-

know environments. Dissemination of classified data must be controlled
according to user clearance, and rests on the proper tagging of data to ensure
appropriate access. The eXtensible Markup Language (XML) provides opportu‐
nity for tagging through its extensibility, and as a standard format for data storage,
processing, and transmission. Its widespread usage covers a broad range of appli‐
cations, especially in productivity software such as the Microsoft Office suite.
This paper describes the UI Tags Project which presents a strategy for imposing
security tags within Office Open XML (OOXML) format documents used with
productivity suites. Leveraging the underlying XML of these document types
enforces mandatory and attribute-based access control policies. Project develop‐
ment goals include a comprehensive system based on a native XML database
which allows users to upload new documents as well as read, edit, or delete
existing documents, and controls for derivative classification.

Keywords: Mandatory access control · Attribute based access control · MAC ·

ABAC · XML · OOXML · Confidentiality · Security tagging

1 Introduction

XML, a markup language for describing a wide variety of data, has become a common
means of storing and transmitting information. XML consists of a series of nested
elements, each with an associated set of attributes. The elements, attributes, and structure
of an XML document is typically defined in a schema that describes each element and
attribute, along with data types and legal values for each. Many common document
formats are based on XML [1, 2]. The flexibility of XML makes it suitable for many of
these applications, as well as many others.
Extending these formats becomes a matter of augmenting underlying XML and
schemas. Extension allows insertion of further information. One particular use of this
extended information might be the inclusion of security information within a document.
This security information is leveraged to determine which users have specific accesses
to specific parts of a document, while continuing to allow users to utilize familiar tools
for creation and editing of content.
This is the high-level goal of the UI Tags document management project. This
project strives to create a means of adding paragraph level tagging to Microsoft
Word.docx format documents to enforce mandatory and attribute based access

© Springer International Publishing Switzerland 2016

K. Haltinner et al. (Eds.): CSS 2015, CCIS 589, pp. 19–33, 2016.
DOI: 10.1007/978-3-319-28313-5_2
20 L. Kerr

controls by manipulating the underlying XML directly in an automated fashion. This

allows a user to create, edit, and delete document content under security constraints
contained within the document itself. UI Tags leverages a native-XML database to
facilitate storage and retrieval of tagged documents.
The remainder of this document is organized as follows. Section 2 discusses back‐
ground research in mandatory access control (MAC), attribute based access control
(ABAC), Office Open XML (OOXML), and XML change tracking. Section 3 provides
an overview of UI Tags with a number of goals. Sections 4 and 5 describe development
stages of UI Tags. Finally, a conclusion with future work is included.

2 Background

One high level goal of UI Tags is to provide a system that supports not only MAC tagging
of documents, but also a wider set of ABAC tagging. Tagging builds on Office Open
XML standards, with initial targets being the individual paragraphs within tagged docu‐
ments, while change tracking looks at general approaches for detecting and incorpo‐
rating changes within a general XML tree.

2.1 Mandatory Access Control

The typical model of an multilevel secure (MLS) environment follows much of the
mandatory considerations of the Bell La Padula model [3]. Under this model, system
entities are grouped as either objects or subjects. Objects are resources to be accessed.
Each object is assigned a security level which conveys its relative sensitivity, represented
by the object’s security classification. Subjects are users or processes that require access
to the objects. Each subject is given a security label as well, referred to here as the
clearance level of the subject, or simply level. Both subjects and objects can be addi‐
tionally associated with some number of compartments. Based on the relationship
between the level of an object and the level of a subject, as well as their respective sets
of compartments, the policy determines whether to grant or deny a particular access.
The fundamental comparison of levels and compartments is known as the “dominates
relationship.” Comparison is possible among classifications and clearances as each
represents a totally ordered set. A typical set might include a number of possible levels
such as:

Here U (unclassified) is the lowest level. All other levels are higher, or more sensi‐
tive, up to TS (top secret) which is the most sensitive. Compartments are not ordered as
no individual comparison exists from one compartment to another. Taken together, the
level and compartments form a partially ordered set. The dominates relationship uses
this partially ordered set to determine if one entity dominates another. To dominate an
object, a subject must have a clearance at least as high as the object, while also belong
to a superset of the object’s compartments. A stronger comparison, strict dominance,
requires this same relationship with the additional constraint that the dominating subject
 UI Tags: Confidentiality in Office Open XML 21

has either a higher clearance than the object’s classification or at least one additional
compartment that the object does not belong to.
Two guiding properties form the basis of access decisions. First, the simple security
property states that only subjects which dominate an object are granted read access. Any
subjects which do not dominate an object are denied access as this would represent a
leak of information to lower levels. In a read only environment this single property
suffices, but in dynamic environments where objects are not only read, but created,
edited, and removed, a further rule is necessary. The *-property deals with this instance.
It states that a subject is only granted write access to dominating objects. This ensures
the subject only writes to objects which are at the subject’s level or higher. A strong *-
property takes this further limiting a user to write only to objects with the same level
and compartment set.
One artifact of MAC environments is the potential for polyinstantiation. Polyin‐
stantiation occurs when some object is necessarily described differently at different
sensitivity levels [4]. A user may only see one instance, matching his or her level, or a
user at a higher level might be able to see one or many lower level representations of
the same object. Some have described this as a necessary side effect of maintaining
multilevel data, even exploiting it to maintain cover stories for various entities [4], while
others have sought to limit or eliminate the presence of polyinstantiation [5].

2.2 Attribute Based Access Control

While a number of different approaches have been proposed in the literature, there does
not yet seem to be a clear consensus as to an exact definition or model of ABAC
([6, 7]). A common theme in existing work is the advantage of ABAC in context-aware
or pervasive computing, where the identity of a service consumer is not necessarily
needed or perhaps even known ([6, 8–11], etc.). ABAC is easily configured and presents
the flexibility necessary to handle dynamic environments, though this flexibility comes
at increased costs as changing or analyzing permissions can become a complex task as
the number of attributes increases [7].
For an attribute-based messaging system, Bobba et al. construct policies from
attribute name:value pairs [9]. Access control policies here consist of conditions that
when satisfied, grant access to message recipients or recipient groups. A condition is a
check on values associated with one or more attributes in disjunctive normal form. These
conditions form the policy that in this case governs if a user with a particular set of
attributes can send a message based on the attributes of the recipient.
Cirio et al. extend a role based access control (RBAC) model with ABAC [11]. They
present the difficulties with a RBAC system such as the static nature of role assignments.
ABAC supplements RBAC here, adding flexibility through use of attributes for role
determination as opposed to user identity. Attributes are associated with both users and
resources, allowing dynamic specification of privileges for resources and association of
users with privileges.
Kuhn et al. [7] present a combined role-centric model RBAC-A, where attributes are
used to supplement and further constrain an RBAC model. Roles and attributes are
distinguished from one another based on whether they are static or dynamic. Attributes
22 L. Kerr

that are static, or reasonably static, are used as the basis for roles. These include things
such as office location, position, or nationality. They are not likely to change frequently
if at all. More dynamic attributes such as time of day are leveraged in the ABAC portion
of the combined model. Using static roles and dynamic attributes together can signifi‐
cantly cut down on the number of possible roles and rules. An example system with 4
static attributes and 6 dynamic results in at most 24 roles and 26 rules, whereas a strictly
RBAC or ABAC approach results in as many as 210 roles or rules, respectively.
Jin et al. [6] state the necessity of more clearly and mathematically defining ABAC,
while providing a model for ABAC that is capable of expressing other, more traditional
models such as mandatory, discretionary, or role based access control. Under this model,
each attribute is a function with a specific range that returns a value or set of values for
some entity. Entities include users, subjects acting on behalf of users, and objects repre‐
senting the resources available in the system. Each entity is associated with a finite set
of attribute functions which return properties of the associated entity. Policies are
constructed using constraints on the values of these attribute functions.
Once the basic entities and attribute sets are defined, four configuration points are
defined: (1) authorization policies (2) subject attribute constraints, (3) object attribute
creation time constraints, and (4) object attribute modification constraints [6]. Author‐
ization policies return true or false as access is granted or denied. Using this framework,
the authors are able to create ABAC policies that adhere to DAC, MAC, and RBAC
policies.

2.3 Office Open XML

Office Open XML, or simply Open XML, is a standard that seeks to provide a stable
document format while providing all features offered by pre-existing productivity appli‐
cations [12]. The standard originally appeared as Ecma-376 in 2006, and has subse‐
quently progressed to a fourth edition [13] as well as an International Organization for
Standardization (ISO) standard [2]. These standards provide schemas for the markup
used in various document types including word processing (WordprocessingML),
spreadsheet (SpreadsheetML), and presentation (PresentationML), in addition to a
number of features shared between file types including the organization of and rela‐
tionship between various document components.
Each Open XML file consists of a number of different parts, all collected in a single
package. The contents and layout of the package are defined in the Open Packaging
Conventions (OPC) section of Ecma-376 [13]. An Open XML file is a package that
contains a number of individual XML files referred to as parts that specify document
content, markup, features, and relationships between different parts. It relies on ZIP
technology to combine the various parts into a single object.
Contents of the package are organized in a hierarchy, with each part having a unique
name that includes both the location in the hierarchy and the content name. The name
represents a pack URI used for addressing specific parts within the package [2, 13].
Common parts of interest are document.xml, [Content_Types].xml, app.xml, and
core.xml.
 UI Tags: Confidentiality in Office Open XML 23

For Open XML word processing documents, the document.xml part contains the
main body of text for the document. The metadata associated with an Open XML docu‐
ment is stored in either core.xml or app.xml, depending on the nature of the metadata.
Open XML standards ([2, 13]) define a metadata schema for the core properties common
to all file types in core.xml, but app.xml is reserved for extended properties - application
specific items. The schema for the core properties defines fifteen pieces of information
that can be used, including such items as creator, creation date, last modifier, last date
modified, subject, title, and keywords. None of the metadata elements is required, and
if no data is present, the part as a whole can be omitted. Repetition of elements is not
allowed – for example, a document with two creator elements results in an error. Any
deviation from what the schema allows in the core properties also results in an error.
The extended properties are application dependent, and allow the incorporation of
information beyond the core properties. The same rules apply here – adherence to the
schema, non-repeating elements, etc. The schema governing extended properties defines
nearly twice as many types as the core properties, including such items as application and
version; character, word, paragraph, and page counts; template used; and total editing time.

2.4 XML Change Tracking

In order to support document altering operations, the system must detect changes to both
the document content and the underlying XML structure. Changes can then be collected
in a delta script, essentially a list of all changes necessary to derive a new version of a
document from an original. Traditionally, a “diff” between two files consists of a line-
by-line comparison of different files. This works well for many file types, but misses
structural information when dealing with XML tree based data [14, 15]. Thus, a number
of algorithms deal specifically with the tree structure of XML in detecting and charac‐
terizing changes.
Many of these algorithms tend towards the hashing of elements or subtrees of an
XML document for the purpose of fast comparisons between documents. In many
instances, only leaf nodes of the XML tree are hashed, with interior nodes aggregating
the hashes of their descendants, with the hope of providing a means of pruning subtrees
from the possible search space.
Khan et al. present an algorithm for change detection that generates signatures for
each node in the XML tree [14]. For a leaf node, the signature is computed as a hash of
the contents of the node. All other nodes will have a signature that combines the signa‐
tures of all the child nodes (in this case using XOR). Comparisons between trees are
then only needed if the root nodes differ. Cobena et al. match as large a proportion of
the original tree in the edited tree by leveraging unique node IDs [16]. Lindholm
proposes a three-way merge algorithm for XML documents [17]. A three-way merge
involves an original document, and two replicas of the original that are edited inde‐
pendently. The merge occurs in two stages: (1) each replica is compared to the original,
changes are detected, and two deltas are obtained; (2) the deltas are applied to the orig‐
inal, generating a new document that incorporates changes found in each replica. The
changes that appear in the delta script are based on changing content of a node, or some
structural change (structure here is based on the parent-child relationship in the XML
24 L. Kerr

tree). Conflicts are identified as ambiguous conditions where different changes are
detected in the same node in both replicas. For example, a node in the original document
might contain the text “Hello,” where in the replicas it may contain “Hi” and “Bye”,
respectively. To resolve such conflicts, Lindholm includes the options to either defer
resolving conflicts until post-processing, or to allow for some level of “speculative
merging” – taking a best guess.
The example provided is a date field in a document’s metadata. If two edited replicas
of an original have different dates associated with them, which date should be used for
the merge? This question is left unanswered.
Rönnau, Pauli, and Borghoff use hashes of individual elements, as opposed to
subtrees, to construct a fingerprint [18]. This fingerprint represents the context of an
element and consists of the hash of the element and hashes of other elements within a
specified radius. The hope here is that an edit operation on a specific element is possible
in the presence of other changes – matching some of the fingerprint or context allows
determining where an operation takes place. This allows for delta scripts that do not rely
on absolute addressing of changes, as well as commutative deltas, where the ordering
of operations does not change the end result.
In further work seeking an efficient change detection strategy, Rönnau, Philipp and
Borghoff [19] frame the change detection problem in terms of the longest common
subsequence (LCS), that is the sequence of leaf nodes of maximum length at a specific
depth that appears in both original and edited documents. This algorithm, called
DocTreeDiff, consists of three steps. First, hash values of all leaf nodes and their respec‐
tive depths are computed, from which a LCS is determined. The second step involves
inspecting the ancestors of leaf nodes found to be matching. Differences along the path
to the root element from the leaf indicate structure preserving changes as opposed to
content changes which only occur at the leaves. Finally, the third step investigates nodes
for which no match exists in the opposing document – each of these represents an insert
or delete operation.

3 UI Tags Overview

The UI Tags project seeks to develop an end-to-end solution which enforces tagging of
specific elements within a document, while enforcing MAC and ABAC policies
involving read, insert, update, and delete operations on document content. Challenges
include management of the document metadata, merging document changes across
security levels, and the capacity for queries over a collection of documents to produce
new derivative documents.
The UI Tags Project (or simply UI Tags) encompasses a number of objectives, many
of which have been addressed in prior studies including work in document-level and
hardware-level tagging. Kerr [20] provided early work enforcing tagging in XML docu‐
ments, using custom schemas to define tags to be used as attributes of various elements.
The secure document portion of UI Tags (henceforth referred to as simply UI Tags in
this proposal) extends this work to focus on word processing documents based on Office
Open XML ([1, 2]), a standard format used by recent editions of Microsoft Word.
 UI Tags: Confidentiality in Office Open XML 25

The objectives of the secure document portion of UI Tags include:

1. Enforcement of element level tagging within Office Open XML documents. The
elements tagged depend on the type of Office Open XML document (e.g., word
processing, presentation, or spreadsheet) containing the tagged elements. Current
focus is on MS Word documents, with paragraph level tagging.
2. Utilize an XML database for storage and retrieval of tagged documents. As work
moves to utilize OOXML data, a native XML database seems appropriate, as it
allows for the individual processing and storage of individual OOXML parts that
make up the document.
3. Richer set of tags. While mechanisms are in place to support tagging of documents
with ABAC tags beyond the necessary MAC tags, these ABAC tags are not yet fully
incorporated into the access control decisions.
4. Tools for original classification. Original classification is the initial process of clas‐
sifying information, which is typically limited to specific entities [21]. Having a set
of tools that integrates with Microsoft Word (or any other application the original
classifier might employ when creating documents) will help greatly with the creation
of multilevel documents, specifically limiting the burden of tag creation and appli‐
cation on the user, while ensuring tagging occurs in an appropriate manner.
5. Derivative classification. In a Master’s thesis at the University of Idaho, Amack [22]
extended continuing work on UI Tags adding controls for derivative classification.
Derivative classification can occur when information is derived or combined from
other sources. Information derived from a classified source needs to bear a like
classification, while combining particular low sensitivity items might result in a
combination that requires a higher classification.
6. Read, insert, update and delete operations. A further objective is the support of a
variety of operations on security tagged Office Open XML documents, while
adhering to a defined MAC and ABAC security policy. Possible operations include
read, insert (a new element), update (the content of an existing element), and delete
(removing an element from the document). Read operations are currently supported
through eXist-db.
7. Document change detection and merge. In support of document-changing opera‐
tions, the system must be able to merge changes back into the original document,
while conforming to the constraints of the security policy.
8. Document metadata. One rather interesting observation of Lindholm [17] that
required more work was that the document metadata tends to change inconsistently.
In our MAC environment, document metadata presents a possible leak of higher-
level information to lower levels. The document metadata typically contains infor‐
mation about the document – time created, number of words, creator or last editor
– which could be used to infer more sensitive information. This is also critical in the
presence of document-changing operations.
9. Queries and reporting over document content. The proposed system provides the
capacity to dynamically create documents based on user-supplied queries over a
collection of documents, while adhering to the security policy and providing prov‐
enance for the retrieved data. The documents returned by these queries will essen‐
tially be derived documents, and thus subject to derivative classification constraints.
26 L. Kerr

Also desirable here is the ability to specify the provenance information returned from
the query.
UI Tags is primarily envisioned as a tool for government environments where an
established MAC policy exists, though it could be implemented in any environment
where need-to-know determines access. In a government setting, MAC aspects of UI
Tags enforce the existing MAC control requirements (users with specific clearances and
need-to-know), while ABAC lends a more dynamic access control mechanism (access
based on date or time, nationality of user, etc.). Outside government, medical facilities
could also benefit from such a system. Here need-to-know relates to care for a patient.
Admission or billing staff needs access to patient demographics, but likely does not
require the level of detail into a patient’s care that a physician requires.

4 UI Tags Phase 1

The initial phase of UI Tags began with mandatory access control for XML documents.
Document here are based on a custom XML schema. The schema defines not only the
structure of the elements within the document, but also a series of XML attributes repre‐
senting the security tags. These XML attributes apply to specific XML elements of
interest throughout the document. In this case, the user of the system is the subject, and
the objects are specific elements within an XML document. Each labeled element bears
three attributes. The first two attributes represent the classification and compartments
associated with the containing element. To mitigate some editing issues arising in this
multilevel environment, a preserve attribute is also used to indicate a need to partially
delete an element. This early effort mitigates a number of issues specific to XML while
allowing for four basic database operations. The work culminated in a prototype client/
server system that allowed a user to perform any of the four basic operations on an XML
database while adhering to a MAC security policy.

C, {}
preserve=
"PRESENT"

C, {} S, {}
preserve= preserve=
"PRESENT" "PRESENT"

C, {RED} C, {} S, {} S, {}
preserve= preserve= preserve= preserve=
"PRESENT" "PRESENT" "PRESENT" "PRESENT"

Fig. 1. Example tagged XML tree

 UI Tags: Confidentiality in Office Open XML 27

Kerr [20] defines four basic operations for security tagged XML documents: (1) read,
(2) insert, (3) update, and (4) delete. Each of these operates at the element level within
the constraints imposed by both the simple security property and the *- property. For
each operation, the path from the root element of the XML tree to the target of the
operation is critical – if the path is not fully dominated by the user, there exists the
possibility that the element exists as a child of a more sensitive element, essentially
orphaning the element in the eyes of the user.
Read access is similar to a Bell La Padula style read, wherein the user must dominate
the object. One added attribute, the present attribute, is used here as some editing oper‐
ations my cause undesirable situations as discussed below. If this flag is present with a
value of “REMOVED,” any user with a level matching the level of the element flagged
as “REMOVED” will not be granted access to the element as it is considered deleted as
far as a user of that level is concerned. Consider a user with a confidential clearance,
with membership in no compartments. If this user were to request read access to the
example XML tree in Fig. 1, only three elements would be allowed: the root element,
the left child of the root, and the right child of that child – only those elements bearing
at least a C classification with no compartments and a preserve attribute of PRESENT.
All data of the higher S classification or any elements with compartment membership
are removed from the user’s read view.

C, {}
preserve=
"PRESENT"

C, {} S, {}
preserve= preserve=
"REMOVED" "PRESENT"

C, {RED, BLUE} S, {} S, {}
C, {RED, GREEN}
preserve= preserve= preserve=
preserve=
"PRESENT" "PRESENT" "PRESENT"
"PRESENT"

Fig. 2. XML tree with deletion

An insertion operation, where a user adds a new element, has similar concerns. The
user’s classification must dominate that of the path from the root to the parent of where
the insertion is to occur. Adopting a strong *-property, the inserted element can only
have a sensitivity that matches that of the inserting user’s classification. If this require‐
ment is relaxed, two problems arise: (1) a downward flow of information is possible if
a high level user inserts a new element at a low level, or (2) a conflict occurs when a
low level user attempts to insert an element that may already exist at a higher level. The
adoption of a stronger *-property as described above, where insertions are only allowed
at the user’s classification, prevents this issue. Recalling a C user with no compartments,
28 L. Kerr

insertions will only be allowed at any of the three readable elements, provided the inser‐
tion bears only the classification and compartments of the inserting user. Any insertion
not bearing a C classification with no compartments represents a violation of the strong
*-property.
Each of the other types of access involves changing the XML data, either by value
of some element or attribute, or its structure as in the cases of adding or removing
elements. Deletion of an element presents a number of issues. An element must only be
considered for deletion if it is accessible by the user in a read capacity – a user would
not realistically need to delete an element that the user is unaware of. So as with a read
access, the clearance of the user must dominate the path from the root to the element to
be deleted. A confidential user with no compartments would then only be allowed to
remove elements tagged with a like classification.
A further consideration involves the content associated with the element. The sensi‐
tivity of descendant elements to the deleted element must be considered to ensure only
appropriate data is removed. If the clearance of the user performing the deletion domi‐
nates the sensitivity of all child trees rooted at the element being deleted, there is no
potential for information flow down to lower levels, as any child elements would already
be unknown to lower level users. The deletion of an unknown element does not impact
a low level user.
If the element contains some child elements strictly dominating the user’s clearance,
however, the deletion cannot simply remove the element. As the deleting user does not
know of the existence of the higher level data, no judgment can be made by the user if
the higher level child elements are appropriate for removal. To resolve this situation, a
preserve attribute is used to mark the element to be deleted as removed. The setting of
this flag must propagate to all descendant elements matching the classification of the
deleted element. Once this has been set, the elements “deleted” by the user are no longer
visible to a user of that clearance, but remain visible to strictly dominating users. This
scenario is shown in Fig. 2, where a confidential user with no compartments has deleted
a child element or the root element. As this element has children which the user was not
cleared to view (and are thus unknown to the user), the present attribute is updated to
REMOVED, effectively removing the element rom the user’s view while retaining the
more sensitive child elements for higher cleared users.
With an update action, there are two possible scenarios for the update: either a value
associated with an element is being updated, or that of an attribute. In the first case, the
value of an element is changed (the value here being some child element or some inner
data, but not the tag itself). This operation is allowed for subjects with a clearance that
is the same as the classification of the element being updated – that is, the subject’s level
both dominates and is dominated by the level of the object. The path in this case must
allow the user to have read access to the element (as an update makes no sense for
something the subject cannot read), but does not necessarily determine the ability of the
subject to update the accessible element. This allows the value to be changed while
avoiding any downward flow of information, and prevents any “blind writes” into higher
level data that the subject should not have access to.
The second update scenario, where a subject attempts to update an attribute follows
the same logic as an element update, with a few conditions:
 UI Tags: Confidentiality in Office Open XML 29

1. The classification of the containing element determines the updateability of the

attribute.
2. The classification label attribute cannot be changed by a subject as this would repre‐
sent a potential downward flow of information.
3. Similarly, the compartment attribute cannot be changed.
4. The preserve attribute cannot be added or manipulated directly by users
A further concern here, as with delete, is the possibility of child elements of the
edited node that are of a higher classification than the clearance of the user. These chil‐
dren are not visible to the user and therefore subject to loss if we allow the edit to proceed.
To overcome this obstacle, we employ a series of steps:
1. Ensure both the simple security property and *-property hold for the node with
content being edited.
2. Examine the MaxDescendant values for affected child elements. Those with a value
that strictly dominates that of the edited element must be retained.
3. Set the preserve attribute to “REMOVED” of those elements with higher max
descendants that would be lost by the update.
4. Perform the update to the element, making certain that the “REMOVED” or domi‐
nating descendants are retained.
Following these steps, users can edit content of a node in the XML tree without the
worry that the edits of a low level might displace any child elements of a higher sensitivity.

5 UI Tags Phase 2

Since the early work of Kerr [20], UI Tags has been extended in a number of ways by
coordinated efforts in three different areas: (1) an early cooperative effort among Amack,
Bhaskar, and Kerr worked towards a foundational prototype system leveraging a native
XML database in which individual word processing documents are stored in compliance
with a MAC policy as their individual XML parts; (2) Amack’s work on a derivative clas‐
sification module that operates on documents as they are processed, adjusting tagged para‐
graphs as necessary based on their content as matched to a set of rules [22]; (3) Bhaskar’s
extension of the prototype, adding elements of attribute-based access control [23].
UI Tags Phase 2 work began by extending the Phase 1 tagging approach to OOXML
based word processing documents. Tagging occurs in the document.xml part at the para‐
graph level, largely as the concept of paragraph exists both in the text content of the
document and as a common element in the XML. Most content in the main body of text
within the document is contained within paragraph elements. Other more granular
elements could be used, though these do not necessarily relate to a logical unit of content
in the eyes of the user (text runs, for example, are used to distinguish separate editing
events or other application specific artifacts).
In addition to attaching compartments and labels to XML paragraph elements, a set
of tags appearing at the beginning of each paragraph’s text is also inserted. This allows
for persistence of tag information when the document is opened and subsequently saved,
30 L. Kerr

as any custom XML markup is removed by MS Word, per a court decision involving a
patent on custom XML in Word documents [24].
Using a database for backend storage of XML content led to the selection of native
XML database eXist-db [25]. With eXist-db, individual XML parts of an OOXML
document can be stored, queried, and retrieved using XPath [26] and XQuery [27]
expressions.
On a read request, each individual part of the document is retrieved from the database.
Once the document.xml part is obtained, a check of each paragraph is conducted,
ensuring the requesting user’s clearance dominates the classification of the paragraph.
If a paragraph is not dominated, it is removed from document.xml, resulting in a docu‐
ment containing only those paragraphs a user is allowed to view. In the event there are
no paragraphs viewable by the user, no document is returned.
This work provides limited support for edit operations. The prototype is able to
determine if change has occurred in a document using a fingerprint scheme similar to
Rönnau, Pauli, and Borghoff [18], though this only works on documents that are whole,
not in cases where the user is allowed a view of only a subset of the document. In cases
where the whole document is available, the edited version simply takes the place of the
original – no delta script is generated or applied.
In addition to this issue with change tracking and subsequent merging of different
versions, one other concern of interest was identified in the course of this work. First,
as mentioned by Lindholm [17], metadata management becomes an issue when merging
changes between versions of documents. This is further compounded by the security
policy. Document metadata may itself represent a leakage should higher level informa‐
tion be exposed. For example, a document containing paragraphs with a range of clas‐
sifications is edited by a high level user. If the metadata reflects this change to all users,
lower level users are able to view this and may infer the existence of nature of the higher
level insertion simply by having the identity of the higher level user.
Building on the UI Tags foundational prototype, Amack [22] developed a means of
building and applying derivative classification rules. These rules define specific strings and
the classification that paragraphs containing these strings must bear. The need for deriva‐
tive classification arises when new documents are created based on content in previously
classified documents, with the new content requiring classification in a like manner.
Derivative classification is governed by a classification guide that consists of a
number of classification rules established by an original classifier [21]. Each rule
contains a string that is associated with a specific classification. Should a paragraph
contain the indicated string, it is expected that paragraph will be assigned the indicated
classification. Amack established an XML format for classification rules in UI Tags [22].
Rule creation is facilitated for the original classifier by a rule builder. As rules are created,
they are appended to a rule file stored in eXist-db.
Derivative classification can occur when documents are uploaded to the server as
well as when read requests are submitted. In either case, each paragraph is inspected for
an occurrence of a classification string in the collection of rules. If a match is discovered,
a check for rule expiration is made. Non-expired matching rules result in a check for
dominance. Here only rules that result in a new classification that dominates the existing
classification are allowed. If the rule indicates a new classification that is non-dominating
 UI Tags: Confidentiality in Office Open XML 31

or non-comparable, the change is marked for review and an error condition explaining
the non-dominating result is logged. An original classifier must then review and resolve
these issues.
Bhaskar [23] introduced some elements of ABAC to UI Tags. Attributes in this
context represent further indicators that supplement the MAC labeling which could
include designations such as dissemination and export controls.
Facilitating these ABAC tags presents somewhat of a problem. While the document
is being stored and processed, these attributes can be stored in the XML, but for persis‐
tence (as they will be removed as custom XML) a new solution is necessary as the
addition of further text prepending each paragraph becomes somewhat unwieldy. To
resolve this issue, the use of endnotes is used here in conjunction with XML attribute
tags. Each paragraph still has the security label prefix on each paragraph, accompanied
by a reference to an endnote. In the endnote, where space and readability are not issues,
full details on the classification, compartments, and additional attributes are found,
allowing for persistence in a way that is familiar to the user. While this provides a means
of ABAC tagging, it does not use the tags in access control decisions.

6 Future Work

As UI Tags evolves, a number of areas for further work have emerged. While many of
the previously enumerated objectives have been satisfied with prior work, several critical
issues still remain. Among these are extending the MAC model to incorporate ABAC
features, particularly in how these attributes affect specifically MAC artifacts – the
simple security property, the *-property and polyinstantiation. In coordination with
extending this model, implementing the read, insert, update and delete operations with
support for ABAC constraints is also necessary.
Along with ABAC operation support, metadata management and change tracking
are critical. Metadata needs to be managed in such a way as to remain coherent and
consistent, but not leak any information to lower levels. While change tracking is
supported in a limited way, further work is necessary to adequately track changes under
security constraints.
Finally, dynamic document creation work must be completed, whereby a user is able
to submit a query, and a document containing relevant results is returned, consisting of
information pulled from various documents in the database. These dynamic documents
are subject to MAC and ABAC security constraints, as well as derivative classification,
and must show sources for all information retrieved.

References

1. Ecma, T.C.: Office Open XML (2006)

2. ISO/IEC 29500-1:2012 - Information technology – Document description and processing
languages – Office Open XML File Formats – Part 1: Fundamentals and Markup Language
Reference (2012). http://www.iso.org/iso/home/store/catalogue_ics/
catalogue_detail_ics.htm?csnumber=61750. Accessed 30 October 2014
32 L. Kerr

3. Bell, D.E., La Padula, L.J.: Secure computer system: Unified exposition and Multics
interpretation (1976)
4. Lunt, T.F.: Polyinstantiation: an inevitable part of a multilevel world. In: 1991 Proceedings
of Computer Security Foundations Workshop IV, pp. 236 –238 (1991)
5. Wiseman, S.: Lies, Damned Lies and Databases (1991)
6. Jin, X., Krishnan, R., Sandhu, R.: A unified attribute-based access control model covering
DAC, MAC and RBAC. In: Cuppens-Boulahia, N., Cuppens, F., Garcia-Alfaro, J. (eds.)
DBSec 2012. LNCS, vol. 7371, pp. 41–55. Springer, Heidelberg (2012)
7. Kuhn, D.R., Coyne, E.J., Weil, T.R.: Adding attributes to role-based access control. Computer
43(6), 79–81 (2010)
8. Wang, L., Wijesekera, D., Jajodia, S.: A logic-based framework for attribute based access
control. In: Proceedings of the 2004 ACM Workshop on Formal Methods in Security
Engineering, pp. 45–55 (2004)
9. Bobba, R., Fatemieh, O., Khan, F., Gunter, C.A., Khurana, H.: Using attribute-based access
control to enable attribute-based messaging. In: 2006 22nd Annual Computer Security
Applications Conference, ACSAC 2006, pp. 403–413 (2006)
10. Frikken, K., Atallah, M.J., Li, J.: Attribute-based access control with hidden policies and
hidden credentials. IEEE Trans. Comput. 55(10), 1259–1270 (2006)
11. Cirio, L., Cruz, I.F., Tamassia, R.: A role and attribute based access control system using
semantic web technologies. In: Meersman, R., Tari, Z. (eds.) OTM-WS 2007, Part II. LNCS,
vol. 4806, pp. 1256–1266. Springer, Heidelberg (2007)
12. Ecma Technical Committee 45, “Office Open Xml Overview.” Ecma International (2006)
13. Standard ECMA-376 (2012). http://www.ecma-international.org/publications/standards/
Ecma-376.htm. Accessed 30 June 2013
14. Khan, L., Wang, L., Rao, Y.: Change detection of XML documents using signatures. In:
Proceedings of Workshop on Real World RDF and Semantic Web Applications (2002)
15. Peters, L.: Change detection in XML trees: a survey. In: 3rd Twente Student Conference on
IT (2005)
16. Cobena, G., Abiteboul, S., Marian, A.: Detecting changes in XML documents. In: 2002
Proceedings 18th International Conference on Data Engineering, pp. 41–52 (2002)
17. Lindholm, T.: A three-way merge for XML documents. In: Proceedings of the 2004 ACM
Symposium on Document Engineering, pp. 1–10 (2004)
18. Rönnau, S., Pauli, C., Borghoff, U.M.: Merging changes in XML documents using reliable
context fingerprints. In: Proceedings of the Eighth ACM Symposium on Document
Engineering, pp. 52–61 (2008)
19. Rönnau, S., Philipp, G., Borghoff, U.M.: Efficient change control of XML documents. In:
Proceedings of the 9th ACM Symposium on Document Engineering, pp. 3–12 (2009)
20. Kerr, L.: Polyinstantiation in multilevel secure XML databases. MS Thesis, Department of
Computer Science, University of Idaho, Moscow, Idaho (2012)
21. Executive Order 13526- Classified National Security Information | The White House (2009).
http://www.whitehouse.gov/the-press-office/executive-order-classified-national-security-
information. Accessed 22 October 2014
22. Amack, A.S.: Automating derivative classification in multi-level secure documents. MS
Thesis, Department of Computer Science, University of Idaho, Moscow, Idaho (2014)
23. Bhaskar, D.V.: Software Design Specification for Storing Multilevel Secure XML for Easy
Retrieval. University of Idaho, Moscow (2014)
24. Microsoft Corp. v. i4i Ltd. Partnership - Supreme Court (2010). http://
www.supremecourt.gov/opinions/10pdf/10-290.pdf. Accessed 25 November 2014
 UI Tags: Confidentiality in Office Open XML 33

25. eXistdb - The Open Source Native XML Database. http://exist-db.org/exist/apps/homepage/

index.html. Accessed 22 October 2014
26. Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.F., Kay, M., Robie, J., Siméon, J.:
XML path language (xpath). In: World Wide Web Consort. W3C (2003)
27. XQuery 1.0: An XML Query Language (Second Edition) (2011). http://www.w3.org/TR/
xquery/. Accessed 25 November 2014
 The Search for Trust Evidence

David E. Ott ✉ , Claire Vishik, David Grawrock, and Anand Rajan

( )

Intel Corporation, Chandler, AZ, USA

{david.e.ott,claire.vishik,david.grawrock,anand.rajan}@intel.com

Abstract. Trust Evidence addresses the problem of how devices or systems

should mutually assess trustworthiness at the onset and during interaction.
Approaches to Trust Evidence can be used to assess risk, for example, facilitating
the choice of threat posture as devices interact within the context of a smart city.
Trust Evidence may augment authentication schemes by adding information
about a device and its operational context. In this paper, we discuss Intel’s 3-year
collaboration with university researchers on approaches to Trust Evidence. This
collaboration included an exploratory phase that looked at several formulations
of Trust Evidence in varied contexts. A follow-up phase looked more specifically
at Trust Evidence in software runtime environments, and whether techniques
could be developed to generate information on correct execution. We describe
various research results associated with two key avenues of investigation,
programming language extensions for numerical Trust Evidence and an innova‐
tive protected module architecture. We close with reflections on industry-univer‐
sity researcher collaborations and several suggestions for enabling success.

1 Introduction: The Problem of Trust Evidence

As the number and diversity of computing devices continues to grow at a rapid pace,
there is a need to develop more sophisticated frameworks for establishing trust between
interacting devices. Consider, for example, a set of Internet of Things (IoT) devices in
the context of a smart city. Devices under the control of a user may wish to connect with
peer devices offering information or other services. Likewise, service devices are
designed to connect with user devices, either peer-to-peer, directly, or through a
gateway. In general, user devices are frequently heterogeneous and the context of inter‐
action is dynamic. For example, mobility may enable a large number of devices to
interact in passing as users come and go.
Authentication is one means by which interacting systems may establish a trust‐
worthy relationship. By exchanging private information using a secure communication
protocol, a service device may identify a client device (and/or its user) in order to estab‐
lish trust. Similarly, a client device may use digital certificates or another means to
identify the service and establish trust with the service device. Cryptographic or trusted
computing methods may be employed to ensure the identification process is robust
against man-in-the-middle attacks, spoofing attacks, and other threats to the mutual
identification process.
Our reliance on authentication, however, is not without its problems. While authen‐
tication approaches may reliably establish the identity of a system and/or its user, they

© Springer International Publishing Switzerland 2016

K. Haltinner et al. (Eds.): CSS 2015, CCIS 589, pp. 34–45, 2016.
DOI: 10.1007/978-3-319-28313-5_3
 The Search for Trust Evidence 35

fail to assess whether the system involved is actually trustworthy. An obvious example
is a system infected with malware; while the user may successfully use the system to
connect with a service and pass authentication, the underlying device may independently
launch an attack against the interacting device, attempt to eavesdrop on private data
exchanges, or simply interfere with interaction between the devices. Perhaps less
obvious is a device that has been misconfigured, making it vulnerable to malicious
attacks or privacy breaches. For example, it may lack appropriate software updates or
fail to make use of antivirus software, operating system firewall features, or system
security policies. Also of concern are systems that have had failures or compromises
that leave them in an unknown state. A system may have sustained a breach by a network
bot leaving it in an ambiguous state of health or compromise. Or, a device may have
sustained a hardware failure (e.g., hard drive) leaving it in an unknown state that may
have security implications or be hard to distinguish from an overt attack.
Besides overlooking the operational state of a device, authentication commonly fails
to acknowledge different levels of trust and conditional trust, instead providing a single
barrier to entry and all-or-nothing access to promised services and interaction. Instead
of allowing provisional interaction until a system’s state and operational characteristics
can be verified, it ignores all considerations once authentication credentials can success‐
fully be delivered. One might imagine a more sophisticated scheme that requires addi‐
tional information about the type and state of the system that requests interaction. Simi‐
larly, one might image systems that don’t require authentication at all for non-private
services. However, a system requesting interaction must provide evidence of non-mali‐
cious intent and correct operation.
We refer to information beyond basic authentication credentials as Trust Evidence.
While the precise definition of Trust Evidence is an open research question, it might
include information about:
the authenticity of a device,
a platform’s configuration,
patterns of hardware and software operation with respect to normal behavior,
use of security policy or well-recognized security standards and levels,
mechanisms to protect stored secrets,
measures taken to insure message or data integrity, and
past event history, including remediation actions that have been taken.
Trust Evidence may be generated by request from a system wishing to interact, trans‐
mitted to the peer system for analysis, and then processed or consumed by the peer
system as part of its risk management framework. Two devices may mutually collect
Trust Evidence at the onset of an interaction, or periodically as an interaction proceeds
and enters different phases of data exchange, each with a different set of security consid‐
erations. For example, evidence of secure storage mechanisms may precede the
exchange of confidential information. Or, evidence of software updates and versioning
may precede software-based service interactions.
Trust Evidence may be used to establish whether a peer device or system is trust‐
worthy, to select a threat posture within an unknown or heterogeneous environment, to
dynamically assess the degree of trustworthiness of devices and systems as their software
36 D.E. Ott et al.

and operational environment changes, and to discover trustworthy devices and systems.
Trust Evidence may be seen as a companion to authentication approaches which are still
useful in establishing user or system identity, but which need additional mechanisms to
assess the actual system participating in the interaction.
Trust Evidence includes many open questions to be investigated by researchers
exploring the boundaries of what is possible and desirable in a crowded world of new
devices and device types. How might Trust Evidence be defined? How should Trust
Evidence be created and transmitted? How might Trust Evidence be consumed? Should
Trust Evidence be produced on the fly or stored by a device for future queries? Could
Trust Evidence be obtained and stored by a third party who provides profiles as an
information service? What is the life span of Trust Evidence? When does Trust Evidence
fail to be useful since system and device operation is dynamic and information can
become outdated?

2 Exploratory Research

To better understand how Trust Evidence might be formulated and applied to real-world
scenarios, Intel sponsored a 1-year university research effort involving several academic
teams. Such programs are often referred to by Intel as seedlings since preliminary
research is needed to better identify the right questions to ask and the most promising
approaches for further investigation. In many ways, such programs help to grow the
maturity of a research area and better position subsequent researchers for developing
usable results.
Research by University of North Carolina [1, 2] looked at techniques for game oper‐
ators to validate the behavior of game clients in terms of valid execution paths. Their
approach makes use of symbolic execution to extract constraints on client-side state as
implied by client-to-server messages. Researchers then use constraint solving to deter‐
mine whether the sequence of client-to-server messages can be verified given possible
user inputs, and in light of the server-to-client messages already received. The approach
implies that Trust Evidence may be inferred using symbolic execution of known sources
code and message histories that either follow or fail to follow expected execution
sequences.
Research by UC Berkeley [3] considered the use of a new program representation
referred to as a hybrid information- and control-flow graph or HI-CFG. The represen‐
tation may be used to study program inputs as they go through complex transformations
in order to understand when a system is being manipulated by an attacker and when it
is functioning as expected. Researchers leverage this structural understanding to scale
program analysis beyond what is feasible with monolithic symbolic execution. The
approach uniquely combines both control- and data-flow aspects of a system binary as
it executes, and researchers show the efficacy of their approach for applications like a
PDF viewer and a word processor. The framework might be used to generate Trust
Evidence both within the context of a single system, and by an interacting system that
shares a copy of the HI-CFG for a given piece of software.
 The Search for Trust Evidence 37

Research by Dartmouth College [4] looked at how real-world information security

practitioners, both developers and security officers, lack the appropriate policy language
to provide clear, intelligible, and machine-actionable descriptions of trustworthy
behavior. They propose three policy primitives: compositional reasoning, counting
primitives, and isolation primitives as SELinux extensions and provide two case study
policies to communicate expected process behavior and trust-altering process events.
Continued work looks at refining proposed extensions into more formal policy languages
and developing quantitative and qualitative metrics to evaluate relative effectiveness in
increasing system trustworthiness. The policy language may be used to define and
exchange Trust Evidence between interacting systems.
Finally, University of Washington researchers [5] considered interacting devices in
the context of a consumer home, including desktops, laptops, wireless routers, televi‐
sions, gaming consoles, appliances, healthcare devices, children’s toys, and various
home automation and infrastructure devices. After cataloging potential attack types and
vectors, they present a framework for thinking about device security and risk assessment.
The framework includes device security goals (privacy, availability, command authen‐
ticity, and execution integrity), digital data goals (privacy, integrity, and availability),
and environment goals (environment integrity, activity pattern privacy, sensed data
privacy, and sensor validity). Trust Evidence may be defined using their framework, and
risk assessment may follow from whether sufficient evidence has been provided to insure
each of these aspects.

3 Trust Evidence for Software Runtime Environments

A key outcome of seedling research was the realization that Trust Evidence requires the
ability to verify the correct execution of system and application software, and that
execution predictability was a central issue.
On the one hand, a framework was needed that could evaluate whether the behavior
of a device, directed by system or application software, followed an accepted path or
pattern of behavior that is expected. This idea within the program became known as
baselining. Baselining captures the notion that despite considerable complexity,
security-critical execution sequences often follow predictable patterns of control-flow
behavior, for example, executing frequent user functions or standard system protocol
sequences. This predictability might be captured and used to assess the behavior of a
device or system at runtime, and to generate Trust Evidence for system state, operation,
and configuration.
The notion of baselining is similar to that of control-flow integrity [6] in that it
examines the flow of instructions and control at runtime. But while CFI, which makes
use of control-flow graphs (CFG), binary analysis, execution profiling, and sometimes
static analysis, is interested in strictly enforcing acceptable paths of execution, base‐
lining is a coarser approach that aspires to be more practical. That is, a multiplicity of
approaches may be used to define execution reference points, and the goal is to generate
evidence of trustworthy execution rather than enforce strictly defined execution paths.
In baselining, the degree of conformance to a baseline is an indicator of trustworthiness
38 D.E. Ott et al.

much like guard rails constrain the direction of travel but not the details of the vehicle’s
fine-grained movements from lane to lane.
Baselining also borrows from the notion of anomaly detection [7], for example
intrusion detection systems that build a statistical model of expected network behavior
and then use this model to identify suspicious endpoints and communication patterns.
Approaches to baselining might similarly develop a model of expected system behavior
during software execution, and then apply statistical methods to assess degree of
conformance. Trust Evidence may then be cast in statistical terms and describe the
degree to which a dynamic system conformed to a control-flow or operational schema
defining trustworthy behavior.
The notion of baselining implies the need for a methodology to define reference
points for assessing control-flow behavior of a system or device. Another realization by
university researchers was the important role that a software developer, administrator,
or perhaps even user could play in defining baselines for Trust Evidence. Dubbed inten‐
tion semantics [8], human agents are often in a position to understand and articulate the
intended behavior of system and application software as it directs control-flow behavior,
and to define what actions are acceptable and within the scope of correct functionality.
As such, further research on Trust Evidence should provide avenues for software devel‐
opers, in particular, to define meaningful baselines that can be used for the generation
of Trust Evidence at runtime.

4 Promising Avenues

Intel went on to sponsor a 2-year follow-on initiative enabling university researchers to

explore a more focused notion of Trust Evidence that looks at approaches to software
control-flow baselining, including methods for defining intention semantics. Here, we
describe two of them in some detail: Imperial College London’s pluggable evidence
aggregation language [9–12] and KU Leuven’s protected module architecture [13–19].

4.1 Pluggable Evidence Aggregation Language

Imperial College London researchers approached the problem of software baselining

and intention semantics through a set of programming language extensions to be used
directly by software developers to annotate their program code. The extensions allow a
software developer to express expectations about the path of execution that their soft‐
ware takes, and to generate numerical Trust Evidence by a runtime system that supports
the framework.
Researchers propose three key constructs within their scheme [9]. First is the
expect statement which defines numerical Trust Evidence values for arbitrary execu‐
tion paths or portions of program state. An example is as follows:
 The Search for Trust Evidence 39

In this example, a program variable tracking Trust Evidence is set to a particular value
depending on the calling module within the execution sequence. A higher value repre‐
sents a higher level of trustworthiness during program execution, while lower values
express unexpected sequences or sequences that imply greater risk. (Here, 1.0 is seen
as maximally trustworthy while 0 is seen as totally untrustworthy.) max is a composi‐
tional operator and suggests that the resulting Trust Evidence value should be the higher
value between the newly assigned value and a prior existing value.
While expect blocks generate values indicating trustworthy state or control flow
behavior, policy blocks are intended to generate actions in response to those values.
An example is as follows:

Here, a policy block compares a local trust variable to a pre-defined threshold in order
to decide whether access to a device resource is granted or denied. Blocks like this can
be defined with arbitrary, application-specific logic to consider whatever program state,
control flow, or execution considerations might be relevant. Researchers often refer to
such blocks as policy decision points [10].
A third construct is the switch statement [10]. An example is as follows:

The block builds upon the outcome of the prior block. If deny is the decision, then the
method should return with the deny message and a payload value of-1. If the decision
is inconclusive, then the return message should indicate incon and include a payload
value of-1. Otherwise, another program bock is evaluated as indicated. Researchers refer
to such blocks as policy enforcements points [10] since it is where an evaluated decision
is realized. It, essentially, enforces a baseline expectation given the outcome of actual
execution.
An interesting feature of the ICL framework is the use of numerical values to repre‐
sent degrees of control-flow trust and to quantify the trustworthiness of program state
and other runtime considerations. The scheme allows for a rich, flexible aggregation
framework that can, for instance, test for maximum or minimum values, add values
together, computed weighted averages, create statistical profiles across many program
iterations, and so on. In fact, programmers are free to invent application-specific Trust
Evidence aggregation schemes without constraint. A Trust Evidence profile might be
provided to an interacting system by request, or evaluated by the runtime system itself
which is designed to protect values against tampering.
Researchers go on to develop a trust calculus language that they refer to as pluggable
evidence aggregation language, or Peal+ [12]. The language uses basic conditions
40 D.E. Ott et al.

(predicates indicating numerical trust or risk scores) and inequalities (statements

comparing scores) to create rules, policies, and policy sets. Researchers use the tool
PERLT [11] to verify conditions and to determine satisfiability. PERLT operates on
statements referring to policies, policy sets, conditions, and domain-specifics. There are
two modes of evaluation: verification can proceed explicitly by converting all references
to numerical values and then crunching the numbers, or it can proceed symbolically and
make use of an SMT solver. Researchers use the well-known Z3 SMT solver in their
work, an approach that captures logical dependencies well but constrains the allowable
complexity of underlying formulas.
We might imagine the ICL framework to generate Trust Evidence in one of several
ways. First, a device may present to a requesting device a single score, or perhaps set
of scores, reflecting Trust Evidence evaluations for various layers of a system stack and
applications running on that stack. Trusted Computing Group [20] frameworks and
standards might be utilized to support hardware isolation of values, secure storage, and
attestation support. Alternatively, an interacting device may request an execution profile
that includes a history of Trust Evidence values collected over a period of time or in
response to a particular input provided by the querying device. The resulting profile may
be analyzed by the requesting device, perhaps without disclosing the critical features of
interest. A third alternative might be the use of a third party which requests a Trust
Evidence profile, analyzes it according to well-understood criteria, and then provides
Trust Evidence assessment information on demand.
ICL’s work on programming language extensions and numerical trust data provides
an innovative approach to Trust Evidence. Its features, in particular, support interesting
aggregation and composition functions, and a direct way for software developers to
articulate constraints on trustworthy software execution. Future work includes several
directions. First, the scheme must be combined with approaches that manage the integ‐
rity of Trust Evidence collection and storage within the runtime system, and the commu‐
nication of Trust Evidence to an interacting system. The protected module architecture
described in the subsequent section could serve both of these functions, for example.
Second, researchers might develop methodologies and tools for the creation of Trust
Evidence values. Many schemes are possible and one might imagine a catalog of
approaches that describe how extensions could be applied to various data types, system
IO calls, cryptographic processing, and more. Third, research on compilers could
address how to translate high-level programming language extensions to binary instruc‐
tion flows in efficient ways, especially if architecture support for the framework is
provided on the underlying system. Finally, researchers may continue to explore prac‐
tical use cases for demonstrating annotation semantics.

4.2 Protected Module Architecture

KU Leuven researchers propose the use of a protected software module architecture and
associated programming paradigms to address baselining, and to realize intention
semantics for developers. Trust Evidence follows from attestation features and custom
routines designed to provide evidence of correct system operation.
 The Search for Trust Evidence 41

The framework relies on a memory protected software unit that researchers refer to
as a self-protecting module [13]. Each SPM resides in a protected area of system memory
and is comprised of two key components. First is a public section where the module’s
code and non-confidential data can reside. While the contents of this section are poten‐
tially readable by other processes on the system, the framework provides integrity guar‐
antees that preclude unauthorized modification, even by system software. Second is a
secret section which stores the module’s private data (e.g., cryptographic keys). Read
and write access to the secret section is only possible from within the module itself, a
mechanism that provides a high level of assurance.
To insure the integrity of an SPM’s public section and the privacy of an SPM’s secret
section, a special memory access control model is implemented in one of several ways.
First, researchers demonstrate that a lightweight hypervisor might be used which divides
the system into two virtual machines, a legacy VM and a secure VM. The former hosts
the operating system kernel and user applications while the latter hosts protected
modules. A special security kernel also resides in the secure VM that implements fine-
grained access control. The architecture, which researchers refer to as Fides [13], imple‐
ments strictly enforced entry points that prevent operating system and application
processes from accessing protected modules against access control policy.
A second approach demonstrated by researchers [15] implements this memory
access control architecture as hardware support. Researchers show how extensions to
mainstream microprocessors may also be used to effectively isolate protected modules
and maintain strict adherence to framework access control policy. In fact, researchers
demonstrate that such extensions can be implemented with fairly minimal circuit area
requirements, performance overhead, and power demands.
A third approach demonstrated by researchers is that of operating system kernel
modifications [14, 18]. Researchers use Linux to show that the memory architecture can
be implemented using virtual memory regions that they refer to as compartments.
Compartments have special access control features implemented using standard MMU
features found on most processors. By aligning compartments to memory pages and
then configuring read-write properties using standard mechanisms, the system can be
configured to generate a page fault when a protected module is accessed. The page fault
can then be handled by a kernel extension that implements the protected module archi‐
tecture control policy.
Researchers point out that their framework maintains its trustworthiness guarantees,
even in the face of malware infection on the host system. Attackers are free to use the
framework to create malware that runs in protected module space. But, because memory
protections mechanisms maintain entry point restrictions, the integrity of additional
modules and the confidentiality of their associated secret data is maintained. In fact,
their threat model is one that makes very few assumptions about attacker capabilities
and doesn’t preclude the possibility of malicious code running at user- or kernel-level
on the same system.
Compiler support for protected modules is considered in their hardware-based imple‐
mentation known as Sancus [15]. Researchers show that simple developer hints desig‐
nating which functions should be protected is enough to apply automated LLVM-based
tools that compile standard C files into the protected module architecture automatically.
42 D.E. Ott et al.

The compiler will also protect the runtime stack by placing it in the protected module, and
it will use an ID scheme to track logical entry points for subsequent reference. Crypto‐
graphic techniques are used for secure linking. Modules also clear registers when they exit
at runtime in order to avoid information leaks.
An interacting system may build trust in software running on the protected module
architecture by making use of cryptographic features built into the framework. The
architecture supports secure communication channels and remote attestation that
provides a robust method for confirming module identity and integrity. Researchers
apply a cryptographic hash to the secure module’s public section which can then be
reported to an interacting system [14, 18]. Included in the associated security report is
also the layout of the module and a cryptographic signature. An instruction for
computing the MAC of a protected module is included in the hardware implementation
of the scheme [15]. A secure exchange protocol, including a nonce mechanism to counter
replay attacks, is used to communicate the value to an interacting system looking to
verify the module.
Trust Evidence may also be generated by the use of trust assessment modules running
within protected memory regions as protected modules. For example, a trust assessment
module may be developed that examines the state of the system’s process table, generates
a cryptographic hash of system binaries, reports on applications running on the system,
summarizes system configuration, or samples an application’s call stack as it is running
on the system. Modules can be highly customizable and directed at particular aspects of
a runtime system. Trusted modules may be designed to interact with another system in
specific ways, handling queries and implementing specialized communication and attes‐
tation protocols.
KU Leuven’s protected module architecture effectively provides a zero-software
trusted computing base, or TCB. That is, its protection scheme can be made to work
without relying on software running on the device. In fact, it will continue to work even
when malicious software is running with kernel level privileges on the system. Its remote
attestation features and support for trust assessment modules makes it a strong approach
for addressing the problem of Trust Evidence. Future work might include developing
an extensive body of programmer tools and methodologies for leveraging protected
modules in real-world software and understanding how protected memory implemen‐
tation approaches map to different device types within IoT and other heterogeneous
device contexts.

4.3 Related Work

Execution profiling is described by Elbaum and Munson in [21], although authors focus
on the problem of intrusion detection and not Trust Evidence. As mentioned earlier,
control flow profiling has been widely explored since then and many of the approaches
and results are described in [6]. Some additional approaches to Trust Evidence include
mathematical formulations [22, 25], reputation schemes [23], learning models [24], and
hybrid frameworks [26].
Other documents randomly have
different content
de avestruz y demás adornos de la religiosidad musulmana, son conocidos
en todo el mundo. El grabado antiguo, la fotografía y la tarjeta postal han
popularizado el interior de este monumento, que es el más antiguo de la
cristiandad europea, y puede ser llamado el Partenón del arte bizantino.
La luz que penetra por las ventanas de la cúpula toma una densidad
amarillenta de ámbar. La capa de pintura con que han cubierto los turcos las
imágenes de los muros, contribuye á colorar el ambiente de este tono suave.
La repugnancia religiosa de los musulmanes á toda representación de la
forma humana, ha borrado los deslumbrantes mosaicos bizantinos, en los
cuales santos y emperadores de rostro puntiagudo y miembros alargados,
destacábanse con rigidez hierática sobre un fondo de oro.
Es el único vandalismo que se han permitido los otomanos. Las
hermosas columnas, los arcos de graciosa majestad, los huecos de las
capillas, las balaustradas de jaspe, todo se mantiene lo mismo que en
tiempo de los emperadores de Bizancio. La costra de pintura amarilla se ha
caído en algunas partes del muro, y el mosaico antiguo brilla con una luz
mate y discreta, como una venerable armadura de oro al través de los
desgarrones de una capa vieja. Unos cartelones verdes de diez metros de
diámetro, con inscripciones gigantescas en honor de Alláh, y cuatro ángeles
pintados en el arranque de la bóveda, son todos los adornos que el arte turco
ha osado añadir al templo erigido por Justiniano. Los ángeles son
convencionales. Cada uno de ellos está representado por cuatro alas en
forma de rueda. La pintura musulmana no puede ir más allá.
Un interminable susurro, un batir incesante de plumas, llena el ambiente
ambarino y crepuscular de la mezquita, uniéndose al crepitar de las
lámparas y á la cantinela monótona de los aprendices eclesiásticos, que,
encogidos sobre las rodillas, balancean el cuerpo cantando de memoria
suras enteras del Korán, mientras un efebo, con el libro entre las piernas,
sigue con la mirada el texto, para corregir el más leve olvido. Centenares de
palomos obscuros, con plumas de metálicos reflejos, aletean en las bóvedas,
descansan en capiteles y cornisas, ó descienden hasta las cabezas de los
fieles, inmóviles como estatuas en su oración, posándose por unos instantes
en sus brazos. Con frecuencia abandonan desde lo alto sus superfluidades
digestivas, y los servidores de la mezquita tienen que limpiar continuamente
la fresca estera del pavimento, sobre la cual marchan los fieles descalzos y
con los pies limpios, para que después el buen creyente, al prosternarse,
pueda besarla sin contagio alguno.
 Ocurre en este grandioso monumento, al contemplarlo por primera vez,
lo que en San Pedro, de Roma. La vista lo abarca todo sin extrañeza alguna.
Un templo poco más grande que los otros... y nada más. Sólo cuando se
avanza, y la perspectiva va prolongándose á cada paso, es cuando se da
cuenta el visitante de la enormidad de proporciones que van surgiendo de
esta armonía general. Lo que de lejos parecían esbeltas columnas, son
troncos enormísimos de piedra, junto á los cuales el hombre se iguala á la
hormiga: las distancias entre una arcada y otra se prolongan mágicamente,
como si el templo fuese creciendo y estirándose á cada paso que se avanza.
La antigua basílica es enorme, abrumadora, soberbia, y sin embargo, da
una impresión dulce, de suave ligereza.
Su historia es tan accidentada como la de una nación.
Santa Sofía no fué elevada en honor de una santa de este nombre, como
muchos creen. Sancta Sophia es una invocación á la Santa Sabiduría, y en
honor de la Sabiduría divina elevó Constantino la primera basílica, en el
mismo lugar que ocupa la actual. Cien años después la quemó el populacho,
creyente y revoltoso, excitado por el destierro de San Juan Crisóstomo.
Teodosio II la volvió á construir, y en 532 la incendió de nuevo el pueblo de
Bizancio, amotinado esta vez, no por un santo, sino por una cuestión de
Circo, el motín de los Victoriatos, en los primeros tiempos de Justiniano.
Fué este emperador legista, manso marido de la interesante Teodora,
mezcla de voluptuoso tirano oriental y austero teólogo, quien creó el
monumento que aun hoy subsiste, y que vivirá siglos y siglos.
Quiso en sus ambiciones de gloria que el templo á la Santa Sabiduría
fuese «la obra más magnífica que se hubiese visto después de la creación»,
y en todas las partes del vasto imperio de Oriente hizo recoger los
materiales más preciosos: mármoles, columnas y esculturas. Los
monumentos de la antigüedad griega fueron saqueados. Éfeso le envió las
columnas de jaspe verde de su famoso templo de Diana; Roma, las que
había robado del templo del Sol en Heliópolis, é igualmente fueron puestos
á contribución los santuarios de Atenas, Delos, Cizica é Isis y Osiris, en
Egipto. Dos arquitectos griegos, los mejores de la época, Antemio de Tales
é Isidoro de Mileto, se encargaron de la dirección de los trabajos; pero la
credulidad popular, ansiosa de lo maravilloso, propaló que un ángel había
entregado á Justiniano los planos del monumento con el dinero necesario
para construirlo.
 Diez mil obreros, dirigidos por cien maestros alarifes, trabajaron á la
vez. Una capa de betún de veinte varas de espesor, que llegó á adquirir la
dureza del hierro, sirvió de base al edificio. Los alfareros de Rodas hicieron
los ladrillos para la bóveda de una tierra tan ligera, que doce de ellos no
llegaban á pesar lo que un ladrillo ordinario. Todos ellos llevaban una
inscripción: «Es Dios quien me ha fundado y Dios me socorrerá.»
La construcción fué una mezcla de esfuerzos arquitectónicos y
ceremonias religiosas. Los sacerdotes bendecían los materiales,
acompañaban con plegarias la erección de cada columna, y al elevarse los
muros, los albañiles introducían en la argamasa huesos de santos y otras
reliquias.
Sumas inmensas se consumieron en este alarde arquitectónico, y
Justiniano se vió en los mayores apuros, y recurrió á los medios más
criminales para conseguir dinero y terminar la casa de la Santa Sabiduría.
Por fin, en 537 la obra quedó acabada. Después de una marcha triunfal por
el Hipódromo, con todo el esplendor de su corte bizantina, y de pródigas
distribuciones al populacho, hambriento de pan y ahíto de disputas
teológicas, Justiniano inauguró el monumento.
—¡Gloria á Dios, que me ha juzgado digno de terminar esta obra!—gritó
al entrar—. ¡He vencido á Salomón!
Catorce días duraron las plegarias, los festines públicos y las
distribuciones de dinero.
La Santa Sapiencia vivió siglos en una relativa tranquilidad, sin otros
accidentes que los que sufren los monumentos gigantescos, eternos
enfermos necesitados de cuidados y reparaciones. Toda la vida del imperio
de Bizancio se reconcentró en ella. Bajo sus bóvedas se consagraron
aquellos emperadores que se asesinaban unos á otros, se sacaban los ojos, ó
degollaban en masa á sus súbditos, por si el Hijo era igual al Padre, y otras
sutilezas teológicas, que tomaron el carácter de verdaderos programas
políticos.
El día que los turcos sitiadores acabaron por penetrar en Constantinopla,
una muchedumbre de sacerdotes, mujeres y combatientes fugitivos se
amontonó en la santa basílica, que tenía ya cerca de mil años de antigüedad.
El caudillo victorioso entró á caballo hasta el altar mayor, y gritó agitando
su cimitarra: «No hay más Dios que Dios, y Mohamed es su Profeta.»
 ¡Se acabó la Santa Sapiencia! Las cruces rodaron por el suelo, los sables
se enrojecieron hundiéndose en la muchedumbre cristiana, y el saqueo y la
matanza dentro de la basílica duraron tres días.
En el momento de la entrada de los turcos, un sacerdote celebraba la
misa, y huyó del altar con el sagrado cáliz, desapareciendo por una
puertecilla practicada en una de las galerías. Inmediatamente la puerta se
cerró milagrosamente, con una pared de piedra que nadie pudo distinguir
del resto del muro. El día que Santa Sofía sea devuelta al culto cristiano y
los turcos huyan expulsados de Constantinopla, volverá á abrirse la puerta y
el mismo sacerdote acabará su misa interrumpida.
Esto lo sé por mi guía Stellio, un honrado griego, verídico y creyente,
que me acompaña á todas partes, discurriendo el medio más rápido y seguro
para extraer el dinero de mis bolsillos.
Los historiadores de Santa Sofía dicen que esto es una leyenda; pero
Stellio se ríe de su ignorancia.
Todas las viejas del barrio del Fanar, residencia de las antiguas familias
griegas, piden á Dios que no las llame á su seno sin haber visto antes á ese
pobre sacerdote, que aguarda entre paredes, durante cuatro siglos y medio,
el momento de terminar su misa.

XXVII

El Papa griego
El barrio del Fanar es Bizancio que se sobrevive. Los griegos, antiguos
señores de la gran ciudad, se refugiaron en este barrio después de la
conquista turca, y allí continúan, en viejos palacios adosados á murallas
medio derruídas del tiempo de los Paleólogos.
Los guerreros bizantinos se hicieron comerciantes después de la derrota,
ó mejor dicho, continuaron siéndolo, pues en tiempo de su imperio siempre
fueron mercaderes, dejando la defensa de su país confiada á bravos
mercenarios comprados en Asia ó en Bulgaria.
La fama de los comerciantes fanariotas ha sido universal. Durante
siglos, el oro de todo el mundo se amontonó en este barrio del Fanar. Los
turcos belicosos, ocupados en hacer la guerra á la cristiandad, dejaron á los
griegos, vencidos y astutos, el manejo de sus riquezas, y el fanariota fué el
intermediario entre Asia y Europa, el mercader de los objetos preciosos de
Oriente, y al mismo tiempo el proveedor y prestamista de sus señores
otomanos. Este barrio del Fanar ha sido durante siglos una Venecia, una
Génova, de poderoso movimiento comercial. Una gran flota mercante
movíase en los mares de Oriente y en todo el Mediterráneo, siguiendo las
inspiraciones de sus mercaderes. El Cuerno de Oro, que lame con sus aguas
las piedras verdosas de los edificios del Fanar—palacios obscuros con
balcones bajos, que casi se tocan con la cabeza—, veíase cortado
incesantemente por las galeras que llegaban de las escalas de Siria y el Mar
Negro y partían hacia los puertos de Nápoles y Marsella.
Hoy el Fanar está solitario y tranquilo. Junto á sus muelles no se ven más
que viejas barcazas en reparación, y enfrente, al otro lado del brazo de mar,
los navíos de guerra turcos, los buques antiguos que sirven de pontones, y el
palacio del Almirantazgo rodeado de las innumerables construcciones del
Arsenal. Mas los fanariotas aun viven tan ricos y poderosos como en otros
tiempos. Los nuevos puentes que dificultan la navegación en el Cuerno de
Oro, el gran calado de los buques modernos y las exigencias del comercio,
les han obligado á trasladar sus oficinas á Galata, cerca del Bósforo, en
medio de los chorros de vapor, rugidos de sirena, chirriar de grúas y
ensordecedora y negra actividad de un puerto de nuestros días.
Pero las venerables casas del Fanar son, como en otros siglos, á modo de
un título de nobleza para los que las habitan, y en ellas siguen viviendo las
familias de estos griegos, más griegos que los que habitan Atenas, y que
hacen remontar sus orígenes en línea recta á los tiempos gloriosos del
imperio bizantino.
El pequeño reino actual de Grecia se nutre de la rica savia del Fanar.
Todos estos helenos de Constantinopla son grandes patriotas, con el
entusiasmo nacional excitado por largos siglos de servidumbre y desgracia.
Son riquísimos, pero no tienen una patria. Fingen sumisión al turco, á quien
explotan, pero su pensamiento va á todas horas á la pequeña nacionalidad
formada en torno de la acrópolis ateniense, viendo en ella como un huevo
del que resurgirá un pasado glorioso.
¡Atenas! ¡Constantinopla!... Estos dos nombres de gran sonoridad
excitan á todas horas su entusiasmo. Todos conocen en el Fanar los
misterios del porvenir. Grecia volverá á ser lo que fué: se apoderará de la
Macedonia, se extenderá por las riberas de Asia, pasará un día los
Dardanelos, y la antigua Bizancio será otra vez helena, brillando sobre la
cúpula de Santa Sofía la cruz del Santo Sínodo, en vez de la media luna de
oro. Y enardecidos por una fantasmagoría tan generosa, no hay sacrificio
que no hagan estos comerciantes avaros, capaces de los mayores crímenes
en el curso de los negocios, y que, sin embargo, desparraman el dinero á
manos llenas en empresas patrióticas.
Los griegos del archipiélago vuelven sus ojos al Fanar cada vez que
intentan moverse. La sublevación de los isleños de Candía, las guerrillas
macedónicas, la misma guerra turcohelena de hace pocos años, que tan
grotesco y vergonzoso final tuvo para los nietos de Temístocles, y la
agitación presente, que convierte las fronteras griegas en perpetuo campo de
combate, todo es obra del dinero fanariota, que corre pródigamente, como
sangre vivificadora del patriotismo. El griego de Constantinopla es un buen
súbdito del sultán, incapaz de provocar ningún disturbio. Procura separarse
del armenio revoltoso, que intenta revoluciones dentro del imperio, pero
trabaja y sacrifica su fortuna por crear á éste en el exterior toda clase de
conflictos.
No sólo piensa en su pequeña patria para lanzarla á la guerra contra el
país en que vive. Sabe que los pueblos son grandes por algo más que las
armas y que la fama imperecedera de la antigua Grecia no se asienta en los
ruidosos triunfos sobre los persas, sino en las enseñanzas y las inspiraciones
de los filósofos, poetas y artistas, gloriosos abuelos de la presente
humanidad. La grandeza intelectual de su raza preocupa á los fanariotas
hasta el punto de que en Grecia es insignificante la instrucción pública
costeada por el gobierno, en comparación con la que sostiene la iniciativa
particular. No muere un griego rico de Constantinopla que no deje fuertes
legados para las escuelas de su país. Muchos han dejado dos y tres millones
de francos. Innumerables escuelas del archipiélago, grandes universidades,
valiosas bibliotecas se sostienen con herencias de patriotas del Fanar, que
pasaron su vida explotando á turcos y cristianos y dando las más fieles
muestras de adhesión al sultán que aborrecen.
Además, el Fanar es para todos los griegos del mundo el barrio santo, la
tierra sagrada donde tiene puesto un pie Dios: algo semejante á lo que es
para el católico el barrio de Roma inmediato al Tíber, donde alza la basílica
de San Pedro su enorme cúpula y se alínean perforando la piedra las
innumerables ventanas del Vaticano.
 En el Fanar está el palacio del Patriarcado, la residencia del Papa griego,
llamado vulgarmente Patriarca de Constantinopla.
Este representante de Dios es un personaje poderosísimo, un sacro pastor
que extiende su cayado de oro sobre millones de místicas ovejas. Si el Papa
de Roma no tuviese al otro lado del Atlántico la antigua América española,
su colega de Constantinopla sería tan poderoso como él. Grecia, Bulgaria,
Servia, Rumania, Montenegro, los cristianos ortodoxos de la enorme
Turquía, que son millones, y la inmensa Rusia, que aunque autónoma
religiosamente, respeta, sin embargo, al sumo sacerdote de Constantinopla,
forman el feudo espiritual de este pontífice que vive en el barrio del Fanar y
una vez al año bendice toneladas y toneladas de aceite, convirtiéndolo en
óleo santo que envía á los metropolitanos y popes de sus Estados.
El patriarca actual es Joaquín II. Un amigo suyo, que á la vez lo es mío,
me invita á visitar al Pontífice, ensalzando la llaneza de su trato y
costumbres. ¿Por qué no?... El amigo añade que ya ha hablado de mí á Su
Santidad, y una tarde á las dos, llegamos juntos al palacio del Patriarcado.
Es un enorme caserón sin adorno alguno, situado en la cumbre de una
colina vecina al Cuerno de Oro. Una tapia alta cierra los patios exteriores, y
ante la triple puerta de entrada hay un cuerpo de guardia.
Su Santidad es después del Gran Imán el primer funcionario religioso del
Imperio. El sultán lo recibe con frecuencia y vive en las mejores relaciones
con él, temiendo la influencia que puede ejercer sobre varios millones de
almas que forman parte del pueblo otomano. Los soldados turcos,
fervorosos musulmanes, velan, bayoneta en el fusil, sobre la existencia y el
reposo de este sacerdote extraño á sus creencias, lo mismo que en Jerusalén
montan la guardia cerca del sepulcro de Cristo. Además, Su Santidad recibe
del sultán una paga enorme, uno de esos sueldos inauditos que sólo puede
concebir la prodigalidad de un soberano oriental.
Joaquín II es bueno y tan generoso al repartir como el sultán al dar. Vive
sin aparato, como en los tiempos que era un pobre teólogo en una
universidad de Grecia, y su enorme asignación la devora el populacho del
Fanar, que descansa en sus tugurios como una nube de langosta en torno del
Patriarcado.
Entramos en éste por una puerta lateral. El arco del centro está cerrado, y
sólo se abre, con largos intervalos de años, en las grandes conmemoraciones
religiosas.
 En el interior encontramos unos criados, bigotudos y morenos,
semejantes á los piratas antiguos del archipiélago, y popes jovencitos que
deben ser familiares de Su Santidad. Subimos una escalera de madera con
esterilla de junco. Las paredes están adornadas con pinturas de imágenes
bizantinas y retratos de patriarcas. Entramos en un salón de espera
igualmente modesto, con la misma esterilla é idénticos retratos de
patriarcas: cabezas venerables y barbudas, con la mitra cuadrada y lóbrega
envuelta en una gasa fúnebre que pende sobre los hombros y la cruz de oro
destacándose sobre el pecho negro.
Se abre una puerta, y avanza unos pasos en la inmediata habitación un
pope de estatura enorme, un venerable gigante que mueve los brazos
invitándonos á entrar.
Hermoso hombre. Yo, que no soy bajo de estatura, tengo que echar atrás
la cabeza para verle bien. Tiene blancas, con una nitidez de nieve, las
barbas luengas y ensortijadas; blancas igualmente, las guedejas que se
escapan de su alto gorro, semejante á un sombrero de copa sin alas. Pero el
rostro es joven, y aunque algo demacrado, da una impresión de fuerza y
salud, por el lustre de la tez, de un moreno rojizo, y la solidez ósea de la faz.
La nariz, un tanto grande y demasiado aguileña, es sin embargo hermosa
por su pureza de líneas, sin la más leve desviación. Los ojos, grandes é
imperiosos, ojos de mando que se esfuerzan por ser dulces, parecen gotas
de densa tinta, brillando un pequeñísimo punto de luz en su negra
intensidad.
Este gigante, blanco, fuerte y majestuoso como un Padre Eterno, se agita
al andar con enérgicos movimientos y encorva la espalda para ponerse al
nivel de los que llegan. Mi amigo se inclina al coger su diestra y besa un
gran anillo. Entonces reparo en la faja de seda que ciñe la sotana del
arrogante sacerdote y en la cruz que brilla sobre su pecho, con un suave
fulgor de oro antiguo. Es Joaquín II.
Mi amigo le habla en griego brevemente, y yo adivino por las miradas
que hace mi presentación.
—¡Ah, Blascos!—dice el Patriarca con una voz sonora de barítono, al
mismo tiempo que me coge una mano y tira de mí para que avance—.
¡Blascos Ibañides!...
Cualquiera diría que Su Santidad se había pasado la existencia no
oyendo otro nombre que el mío. Es la amabilidad superior de los soberanos,
de los grandes personajes que fingen conocer á todos los que llegan y
parecen recordar sus nombres, que les han dicho momentos antes. Y
repitiendo mi apellido desfigurado á la griega, con una expresión satisfecha,
como si no conociera otra cosa, me empuja con su volumen de coloso, me
hace sentar en un diván redondo en el centro de la pieza, y él vuelve al
sillón dorado y viejo que ocupaba momentos antes.
La sala, larga y estrecha, es una galería cerrada con cristales. Al través de
ellos, se ve abajo parte del caserío del Fanar, y más allá de los tejados, una
mitad del Cuerno de Oro, los navíos de guerra, el Arsenal, y los montes
desnudos de la ribera de enfrente, con abandonados cementerios turcos, en
los cuales las blancas fichas de las tumbas dan la sensación de lejanos
corderos rumiando inmóviles en las laderas.
El Patriarca está sentado de espaldas á los cristales, con el cuerpo en la
sombra y rodeado de un nimbo de luz que forma el sol de la tarde en torno
de su alba cabellera. Junto á él sonríe un joven pequeño, vestido como un
gentleman, el monóculo brillante sobre el rostro afeitado y el pelo rubio y
lustroso partido por una raya central en dos bandós que caen sobre la frente
cual lacios cortinajes. Es el secretario de la legación de Grecia, que está en
conferencia con el Patriarca y juntos pasan el tiempo hablando de los
asuntos del amado país.
Joaquín II habla en su idioma, de sonora armonía, ininteligible para mí, y
al terminar mi amigo, que parece emocionado en presencia del Patriarca y
apenas osa levantar los ojos, me dice en francés:
—Su Santidad está muy contento de verle, y dice que le es usted
simpático... Además le desea una estancia muy feliz en Constantinopla.
—Su Santidad es muy amable. Dele usted las gracias.
Quedamos los cuatro en profundo silencio, mirándonos, como es de
buen tono en toda visita oriental, donde la conversación animada no surge
más que tras larguísima pausa luego de haber tomado el café.
El Patriarca ha dado sus órdenes con una voz de marino que ordena una
maniobra, y aparecen los criados trayendo el inevitable obsequio de toda
visita.
El café no es gran cosa, los cigarrillos son comunes y el servicio de
porcelana de lo más vulgar. Joaquín II vuelvo á repetir que vive
pobremente, como un hombre de escasas necesidades. Nos ofrece las tazas
y los cigarrillos con ademanes de graciosa cortesía, pero él no bebe ni fuma.
Sólo la confitura es magnífica: un dulce de exquisitez monacal, formado de
diversos y misteriosos aromas: un regalo tal vez de lejano convento, ó de
algunas griegas devotas, enclaustradas voluntariamente en algún ruinoso
palacio del Fanar.
El Patriarca, sin dejar de mirarme, habla al joven que tiene al lado. Este
sacude su actitud indolente, se desenrolla en el interior de su sillón, y
avanza la cabeza, en la que parece pegado el monóculo, sonriéndome con
diplomática calma. Su Santidad sólo habla el griego y el turco, pero desea
conversar conmigo. Es la primera vez que ve á un español. Él me traducirá
en francés lo que diga Su Santidad y á continuación le comunicará en
griego lo que yo responda.
—Puede preguntar Su Santidad lo que guste.
Y Joaquín II se lanza á hablar apresuradamente, con un ímpetu de orador
tribunicio, rodando como truenos los párrafos sonoros, en los que abundan
las armoniosas onomatopeyas.
Cuando el Papa se calla, el diplomático hace la traducción,
acompañándola de fina sonrisa.
—Su Santidad dice que siente muchísimo las desgracias de España; que
durante la guerra con América, dedicó muchas veces sus oraciones á
vuestro pueblo, que le es muy simpático, y que comprende que en vuestro
país aun estará vivo el dolor por tan grandes pérdidas.
La lástima bondadosa de Joaquín II me irrita un poco.
—Dígale á Su Santidad que no hay para qué lamentarse de lo pasado;
que en mi país ya nadie se acuerda de eso, y que habiendo perdido hace un
siglo casi toda la América, no había razón para conservar unas cuantas islas
que eran en cierto modo un bagaje pesado.
El Patriarca, de ojos imperiosos, es un intuitivo, de rápida penetración.
Mirándome fijamente parece adivinar mis palabras, mueve la cabeza como
si me entendiese, y cuando el secretario hace su traducción, él se adelanta
completando las ideas.
Continúa el diálogo entre Su Santidad y yo, con la mediación del
elegante intérprete. Joaquín II se entera con gran interés de las costumbres
españolas, de las que tiene una vaga y fantástica idea, y me pregunta
especialmente por nuestra literatura nacional.
 Él, gran erudito en letras clásicas, comentador de Homero, como todo
griego ilustrado que se respeta un poco, no conoce nada de España. Hace
muchos años, cuando no era en Atenas más que un simple pope dedicado á
enseñanzas teológicas, vió un drama español traducido al griego, un drama
de un señor que se llamaba... se llamaba...
Y el patriarca y el diplomático se consultan con la mirada, al mismo
tiempo que pugnan por pronunciar un hombre, sin llegar á completarlo en
sus dudas.
—Echegaray—digo yo, adivinando sus balbuceos.
Su Santidad sonríe moviendo la cabeza. Eso es, Echegaray. El Patriarca
guarda un hermoso recuerdo de la obra. Indudablemente fué la única vez
que asistió al teatro el austero sacerdote.
—¿Vive aún monsieur Echegaray?—pregunta Su Santidad con gran
interés por mediación del secretario.
—Vive, y á pesar de sus años es animoso como un muchacho y no
descansa.
Su Santidad vuelve á sonreir, como si bendijese con el gesto al lejano
poeta que alegró con la magia del arte algunas horas de su existencia. Y yo
sonrío también, pensando en el ilustre don José, muy ajeno á imaginarse
que el Papa griego es uno de sus más sinceros admiradores, con esa
admiración del que sólo ha ido una vez al teatro y se acuerda del magno
suceso durante toda su vida.
El Patriarca, después de esto, habla de la literatura griega
contemporánea. Hay en Atenas poca producción; escasos dramas y muy
contadas novelas. Los literatos, antes de dedicarse al trabajo, viven
enzarzados en interminable disputa sobre si deben escribir en griego
antiguo ó en el griego vulgar que hoy se habla en el archipiélago. Esta
disputa apasiona á la nación entera, dividida en dos partidos.
—Su Santidad pregunta qué opina usted sobre esto—dice el secretario.
—Pues dígale á Su Santidad que si novelas y dramas tienen por
protagonistas á personajes de ahora, lo natural es que hablen el griego
moderno, aunque no sea puro. Un mozo de cordel del Pireo no va á
expresarse como el Aquiles homérico.
El Patriarca acoge mis palabras con un gesto cortés, pero deja adivinar
en sus ojos que piensa todo lo contrario.
 La conversación languidece y yo me preparo á marcharme. Llevo más de
media hora con Su Santidad é indudablemente muchos fieles de
importancia aguardan en la antesala.
El Pontífice de Constantinopla es un Papa constitucional. Ni es infalible
por sí solo, ni puede tomar una resolución en materias de fe. Dos veces por
semana se reune bajo su presidencia el Santo Sínodo, compuesto de
eclesiásticos y laicos influyentes, y esta asamblea es la que legisla, dejando
al Patriarca el poder ejecutivo.
Voy á abandonar mi asiento, cuando Joaquín II emprende una larga
arenga dirigida al secretario, en la que percibo varias veces la palabra
democraticón. El Patriarca parece poner un gran interés en lo que dice, y
cuando al fin calla, el diplomático me habla gravemente.
—Su Santidad pregunta si en España los sacerdotes son muy respetados,
si la religión tiene el mismo prestigio que en otros tiempos, si los reyes son
queridos, y sobre todo, si existen partidos democráticos como en otras
naciones desgraciadas, y si el pueblo, movido por malas enseñanzas, intenta
levantarse contra sus mayores.
Quedo indeciso algunos momentos. ¿Qué contestar al buen Patriarca?...
Después de tan buena acogida, siento cierto escrúpulo de decirle la verdad.
¿Para qué discutir con él? ¿Para qué desvanecer la santa ignorancia de este
sacerdote, que ya no volverá á acordarse de España y jamás podrá influir en
nuestra suerte?...
—Dígale á Su Santidad que allá no hay partidos democráticos ni nada de
esas pestes modernas que como él dice hacen la infelicidad de los pueblos.
Los reyes velan por nuestra dicha; los sacerdotes son veneradísimos; todos
los españoles somos católicos...
Joaquín II sonríe, adivinando otra vez mis palabras, y mueve sus
melenas blancas y su gorro negro, como diciendo: «Muy bien.»
—Su Santidad—añade el diplomático al poco rato—dice que se alegra
muchísimo de las palabras de usted, que éstas son para él un inmenso
consuelo, y que España será siempre grande si no se aparta del buen
camino.
Me levanto, despidiéndome del Papa con una solemne inclinación. Su
Santidad está alegre, parece encantado por mis afirmaciones, y me
acompaña hasta la puerta, repitiendo mi nombre con paternal sonrisa.
—¡Blascos! ¡Ah, Blascos! ¡Blascos Ibañides!...
 No me entrega su mano á besar como á los otros. Respeta mis escrúpulos
de buen católico español, pero me acompaña, dándome cariñosos golpes en
un hombro con sus manos fuertes, y la más paternal de las sonrisas contrae
las ondas de nieve de su barba.
Cuando llego á la puerta le parece poco esta despedida, y eleva la diestra
con su gran sortija de oro... y me bendice.
Salgo del Patriarcado admirando la espontánea solidaridad de todos los
que viven á la sombra de la cruz. ¡Extraña y poderosa fracmasonería de los
hombres de sotana! Durante siglos y siglos, el Vicario de Dios en Roma y el
Vicario de Dios en Constantinopla se han insultado con baba rabiosa,
llamándose hijos del diablo, asquerosas víboras y demás insultos inventados
por el rencor eclesiástico, maldiciéndose con acompañamiento de cirios
llama abajo y cánticos de muerte. Ahora fingen no conocerse, ignoran
mutuamente su existencia, viven vueltos de espalda, asumiendo cada uno la
verdadera herencia de Cristo, y sin embargo, por encima de tantos siglos de
abominación y de odio, se entera cada uno de la existencia del otro, y
celebra que ésta sea próspera y fuerte. Lo mismo hacen los comerciantes
cuando preguntan con interés por los negocios de los colegas, y se alegran
de que marchen bien, aunque nada les produzcan, viendo en ellos una
prueba de que el mercado no se debilita, de que sigue la demanda y de que
mientras los clientes no se llamen á engaño habrá ganancia para todos.

Algunos días después, al volver al centro de Europa, el tren que me

conducía chocó con otro de mercancías en las inmediaciones de Budapest.
Cinco muertos y un número enorme de heridos. Yo salí ileso.
Luego en París recibí una carta del amigo que me había presentado al
Patriarca.
Su Santidad, al leer la noticia en los diarios griegos de Constantinopla,
había celebrado mucho la inspiración que tuvo al bendecirme, y repetía
sobre mi cabeza el gesto pontifical, recomendándome de nuevo en sus
oraciones.
Leyendo esto me expliqué mi buena suerte.
 En adelante, siempre que vaya á un país donde exista Papa, pienso no
salir de él sin la correspondiente bendición.

XXVIII

Turcas y eunucos
Cuando un occidental relata su viaje á Turquía, la curiosidad, excitada
por todo lo que es extraño y misterioso, le interrumpe siempre con las
mismas preguntas:
—¿Y las turcas? ¿Y la vida del harem?... ¿Y los eunucos?
¡Las turcas!... Se las ve en todas partes; pasean por los cementerios,
frondosos como jardines; entran tapadas á hacer sus compras en las lujosas
tiendas á la europea, van en la buena estación á solazarse en las Aguas
Dulces de Asia, lugar de moda á orillas del Bósforo; salen en carruaje, ó
transitan á pie por el Gran Puente; se visitan unas á otras; gozan de más
libertad que las europeas; salen á la calle tanto como éstas, y sin embargo,
no hay en Constantinopla nada tan misterioso é inabordable como las
mujeres.
Viviendo aquí, se convence el europeo de la frescura con que han
mentido los novelistas y los poetas al describir amores entre turcas y
cristianos. En otros tiempos, tal vez pudo ser esto. Durante el reinado de
Abdul-Aziz, loco generoso, Nerón oriental, que condecoraba á sus gallos de
pelea con las mismas bandas usadas por los generales, y se divertía
arrojando al populacho espuertas de monedas de oro, tal vez podrían
desarrollarse estos amores internacionales. Abdul-Aziz, apasionado
romántico de la emperatriz Eugenia, debió ser tolerante con las pasiones de
sus súbditas.
El actual emperador Abdul-Hamid, austero creyente que se encierra en la
tradición y el aislamiento de raza para defenderse de la codicia europea,
muestra empeño en evitar que la mujer musulmana tenga contacto alguno
con el cristiano, y vela sobre ella con una minuciosidad de déspota curioso
y activo, que lo mismo ansía conocer el pensamiento del emperador de
Alemania que las intrigas del harem del último de sus pachás.
 Las damas turcas marchan encubiertas por las calles de Pera,
contemplando al través del velo á los europeos, que las siguen con ojos
ávidos. Aburridas por la soledad del harem y la indiferencia de un señor en
el cual el exceso de cantidad embota y debilita todo afecto, ¡cuántas veces
su pequeño cerebro de niña, apenas educada, experimenta la embriaguez del
deseo, viendo en este barrio cristiano la gran abundancia de hombres,
venidos solos del otro extremo de Europa, y á los que un celibato forzoso da
audacias y ademanes de lobo carnívoro!...
Viven libres, sin ver al esposo más que de tarde en tarde; pueden entrar y
salir de su casa sin otra vigilancia que la del eunuco, fácil de sobornar;
disponen de su tiempo mejor que una europea, y sin embargo, la intriga
amorosa es dificilísima para ellas, por no decir imposible.
Que levanten un poco el velo sobre su rostro para dejarlo visible al
hombre que pasa, y al momento, un otomano, que parece distraído en medio
de la acera tomando el aire, seguirá sus pasos cautelosamente, para saber en
qué termina la inusitada audacia. Que se permita un gesto, una mirada
significativa ó volver la cabeza, y el polizonte avisará en el mismo día al
marido ó al padre.
La policía y la fuerza tradicional de las costumbres velan sobre la mujer
turca, la rodean á todas horas, dejándola en completa libertad para todo...
para todo, menos para lo que ella desearía.
Una tercera parte del presupuesto del imperio se consume en servicio
policíaco. Un importante personaje de la corte es el jefe de los espías, y á su
vez hay espías de los espías... y así hasta lo infinito. Todas las clases de
Turquía figuran en el inmenso cuerpo de la delación. Los policías se
reclutan lo mismo entre los mozos de cordel de los muelles que entre los
grandes personajes. Algunos cobran un sueldo mucho mayor que el de un
ministro de Europa. Lo que cuesta al sultán este servicio, representa más
que lo invertido por algunos Estados en ejército, marina, administración y
obras públicas. Muchos de los señoritos turcos que pasean en caique, llenan
los cafés y teatros de Pera y son clientes de los sastres europeos, luciendo
empinados bigotes á lo kaiser, bajo el erguido fez, no tienen otro medio de
existencia que lo que cobran por repetir al ministro de Policía cuanto ven y
cuanto oyen.
Además, para las mujeres, todo turco es un agente que vigila por las
buenas costumbres. El europeo no puede mirar mucho tiempo, y con
marcada atención, á las mujeres que pasan. Imposible seguir sus pasos,
como ocurre en las ciudades europeas. Si es en el barrio puramente turco de
Stambul, corre peligro de recibir como aviso una pedrada ó un palo. Si es
en las demarcaciones europeas de Pera y Galata, cualquier respetable
effendi que pasa junto á él le preguntará cortésmente si es forastero, ya que
le ve faltar tan abiertamente á las costumbres del país.
La mujer, sitiada por la vigilancia del policía y el fanatismo nacional de
todo compatriota, obligada á no hablar con otro hombre que el que tiene en
su casa, se venga de este aislamiento con un orgullo rencoroso, que la hace
antipática las más de las veces. En las aceras empuja al hombre con
soberano desprecio para que le ceda el paso. Cuando van en carruaje se ríen
del transeúnte europeo con una insolencia de colegialas en libertad.
La mujer pobre ó de la clase media sigue fiel al dominó de pesado
damasco y á la cortinilla de gruesa seda que le sirve de antifaz. Así se la ve
pasar, como máscara misteriosa, llevando en una mano la sombrilla cerrada
ó tirando de un turquito cabezudo, y sosteniendo con otra la crujiente
faldamenta, que deja ver las pantorrillas enormes, hinchadas, elefantíacas,
por ir encerrados, dentro de las medias, los extremos de los calzones
interiores.
Pero las grandes damas, las elegantes esposas de los pachás y los turcos
ricos, las moradoras de los haremes lujosos, hace tiempo que, valiéndose de
la moda, han acabado con los trajes tradicionales, que recluían á la mujer en
obscuro incógnito. Bajo el gabán oriental, semejante á una salida de teatro,
llevan trajes de París recargados de adornos y en extremo vistosos. Se
cubren el pelo y parte del rostro siguiendo las exigencias de la costumbre
religiosa, pero lo hacen con el yachmaks, velo tenue y transparente como
una nubecilla, suspiro de seda casi impalpable, que sirve para dulcificar su
rostro, pintado de rosa y adornado con lunares artificiales, para dar mayor
realce á sus ojos, agrandados por una aureola negra de kool. Ocupando
grandes carrozas con ruedas doradas, y bajo la escolta de eunucos negros, á
los que la perturbación del sexo hace luchar con las señoras en chismes,
odios é histéricas rabietas, van á las tiendas ó visitan á las amigas de otro
harem, situado á tres ó cuatro horas de distancia, al final del Bósforo.
Algunas veces un harem se traslada á la orilla de Asia para ver á las
compañeras de un gran señor amigo del suyo. La visita dura tres ó cuatro
días, y esposas y odaliscas, libres de velos y escrúpulos, en el misterio de
las habitaciones privadas, hacen en común sus comiditas de muñecas,
abundantes en dulce, duermen juntas, tocan y cantan, y sobre todo, hablan...
hablan mucho, con una verbosidad de prisioneras ó de monjas, repitiendo
los chismes del silencioso Stambul, donde las casas parecen cárceles, con
sus puertas siempre cerradas y sus ventanas de celosía, tras las cuales espía
á todas horas la curiosidad maligna, la sospecha calumniosa, como en una
muerta ciudad de provincias.
Estas damas, mujeres opulentas á los diez y seis años, saben pintarse las
mejillas de carmín, los ojos de negro y las uñas de rojo, y en esto invierten
la mayor parte del día. Además, las mejor educadas saben fabricar agua de
rosas, dulces de varias clases y á veces hasta bordan gruesas flores de oro
sobre telas de seda.
Hablar, con una charla interminable de pájaro loco, embriagándose en
sus propias palabras, hablar bien de ellas y mal de sus amigas, es su mayor
placer. Se comprende que el buen turco, temiendo pasar el resto de su vida
frente á frente con una sola de estas hermosas muñecas, vacía de cráneo y
expedita de lengua, multiplique su número para encontrar alivio. Pero esta
variedad, cuando todo el harem ha perdido el encanto de lo nuevo, sólo
sirve para aumentar el tormento.
Los turcos modernos, que han viajado por Europa amoldándose á
nuestras costumbres, sólo tienen una mujer y sonríen cuando les hablan del
harem. Están enterados de lo que es la poligamia y compadecen á los turcos
á estilo antiguo, á los tradicionalistas, que por seguir la costumbre tienen
varias esposas.
Sólo un pachá del viejo régimen poseedor de una paciencia inagotable ó
aficionado á murmuraciones y futilidades como una mujer, puede soportar
durante toda su vida el contacto con el rebaño femenino del harem.
Es un error generalizado en Europa creer que la mujer turca, porque se
compra las más de las veces, es una esclava, un objeto, un ser sin derechos
y sin libertad, fuera de las leyes. La religión del Profeta nunca habló con
desprecio de la mujer, ni vió en ella un ser impuro, un aborto del demonio,
como los Padres de la Iglesia cristiana. El hombre tiene sin disputa un alma
superior, porque es el guerrero y pesan sobre él los más rudos deberes de la
vida, pero la mujer es igual á él en toda clase de derechos. La ley
musulmana sólo es implacable y feroz en caso de infidelidad conyugal.
Conoce la escasa solidez de estos seres adorables y sin seso, y presiente que
si abriese la mano y no se impusiera por el terror, ningún musulmán podría
llevar su turbante sobre la frente con entera comodidad.
En los antiguos haremes de Turquía figuraban sobre la puerta dos versos,
que poco más ó menos dicen así:
 Nada iguala
la astucia de la dama.

El encierro (que no es tal encierro, pues la turca sale á todas horas, y

ellas y los eunucos se entienden con la fraternal solidaridad del interés
común) y la prohibición de hablar con los hombres, son las dos únicas
tiranías que pesan sobre las mujeres de alta clase. Pero junto á esto, ¡qué
insoportables derechos, exagerados por la susceptibilidad femenil, gravitan
sobre el infeliz otomano, que entusiasta de las glorias de la vieja Turquía, se
empeña en mantener un harem, como alarde de patriotismo!...
Si hace un regalo á una de sus esposas, por costoso que éste sea, las otras
tienen derecho á otro igual, y pueden llevarlo á los tribunales para
exigírselo. Si una riñe con sus compañeras y declara que le es imposible
seguir viviendo en el harem, la ley turca obliga al marido á que le construya
una casa aparte; igual, absolutamente igual, hasta que satisfaga los gustos
de la esposa. Y se han visto pleitos que han durado años y años, sin darse
nunca por contenta la reclamante al visitar la nueva vivienda, exigiendo
unas veces que tuviese igual número de ventanas que la antigua,
pretextando otras que las lámparas eran menores en número, que los
muebles no estaban tapizados con la misma seda, que las alfombras no eran
antiguas, y así hasta lo infinito de una histeria caprichosa, agravada por la
rivalidad femenina.
Y á más de esto, el amontonamiento de hijos que se forma en pocos años
en un harem rico, donde las esposas y odaliscas son un par de docenas y el
Señor, poderoso personaje falto de ocupaciones, se queda en casa los fríos
días de invierno, y únicamente sale los viernes para ver al sultán en el
Sélamlik.
Yo he conocido á un viejo pachá, entusiasta de las tradiciones, que tiene
trescientos cuarenta y dos hijos. Es un hombre virtuoso, dado á los estudios
teológicos, poco amigo de pecados carnales, y que desprecia á los europeos,
como seres inferiores que á todas horas tienen el pensamiento puesto en la
mujer. Á pesar de la extensa prole, yo no creo en su concupiscencia. En la
vida del harem no hay golpe perdido, y aunque los olvidos de la virtud sean
poco frecuentes, todos tienen consecuencias por la variedad y el número de
la colaboración, llegando el respetable padre á no conocer á sus hijos ni
saber sus nombres, á pesar de que viven bajo el mismo techo.
 La poligamia es un lujo de personajes, y pocas fortunas la soportan. Los
hijos son más costosos aún que las mujeres, pues hay que darles colocación.
Cada sultán se basta él solo para fabricar la mayor parte de los
gobernadores, generales y altos funcionarios de su imperio, y las demás
plazas las proveen, con su fuerza reproductora, los personajes que viven
junto á él.
El harem imperial y el de los grandes pachás son incubadoras de altos
empleados que no dejan lugares libres á los turcos de más bajo origen. Por
algo se transmite el imperio de Turquía de hermano á hermano y no de
padre á hijo, como en las monarquías europeas. Si la sucesión imperial
fuese por este último sistema, Turquía viviría en eterna guerra civil, siendo
centenares los pretendientes al trono que se combatirían, con una saña de
hermanos, cada uno de distinta madre.
Los turcos modernos y jóvenes ríen y ríen del viejo harem. ¡La
poligamia! ¡Tonta inutilidad del pasado!... Ellos viven con sólo una turca, ó
con ninguna, admirando los grandes adelantos de la civilización europea, la
más perfecta de todas para la satisfacción de las necesidades humanas, y
cuando sienten el deseo de la variedad, pasan los puentes y suben á Pera, y
allí encuentran en las calles un harem suelto y por horas, de rumanas,
italianas, austriacas y judías.
*
**
La afición de ciertos personajes á los progresos modernos, ha creado una
clase de turcas más infelices y dignas de compasión que la antigua dama
otomana, devota y contenta de su vida, satisfecha de sus visitas y sus
lujosos trajes, sin otro ideal que una joya nueva ó una banda con placa de
brillantes, regalo del sultán, sin otros horizontes que las montañas de la
ribera asiática, ni otros deberes que incubar nuevos turcos.
Los grandes pachás que envían sus hijos á correr Europa, han traído
institutrices ingleses y francesas para sus hijas. Muchas de las tapadas que
pasan en carruaje, delatando bajo sus orientales velos la frescura esbelta de
los pocos años, la delgadez de una mujer en formación, desprecian las
confituras, odian como perfume vulgar el aceite de rosas y consideran el
bordado como obra de esclavas, sonriendo ante las obras de juventud que
les enseñan con orgullo sus obesas madres. Tienen en una pieza del harem
donde nacieron un piano de cola, en el que tocan los valses melancólicos de
Chopín ó el último couplet de moda en París, y cerca del sonoro Erard una
biblioteca llena de novelas inglesas y francesas. Algunas hasta han roto con
la preocupación religiosa de la raza, que prohibe la reproducción de las
formas vivas, y pintan acuarelas con palomos, flores ó barquitos.
Conozco á una francesa vieja, que vive hace muchos años en
Constantinopla de dar lecciones de su idioma y entra diariamente en ricos
haremes. ¡Las confidencias de estas pobres jóvenes, que han de vivir como
las mujeres del tiempo de Mohamed II, y por la imprudencia de sus padres
llevan bajo las vestiduras orientales la misma alma que una muchacha de
París ó Londres!...
—Sabemos francés, sabemos inglés—dicen á la vieja confidente—.
Tocamos el piano, cantamos, pintamos. ¿Para qué todo esto?... La mujer
aprende para lucir sus conocimientos, para hacer vida de sociedad... para
hablar con los hombres.
Y la pobre turca de moderno estilo sólo podrá hablar con uno, el que les
designe su padre como esposo. Un día la adornarán de piedras preciosas y
se casará con un joven turco, al que sólo habrá visto de lejos, al través de
una celosía, y con el que cruzará la palabra por vez primera en el momento
de ser su esposa. La llevarán á una casa nueva, en la que vivirá como única
señora si su marido no ama las costumbres antiguas, ó en la que se
confundirá con otras, iguales á ella en derechos, distintas á ella en alma,
como si fuesen de otro planeta. Su madre se extrañará de sus lágrimas y
melancolías. Así vivió ella, así vivieron sus abuelas y todas las honradas
damas temerosas de Dios. Pero la madre era feliz, abroquelada en su santa
ignorancia: no la habían hecho morder el fruto embriagador de la cultura
occidental... Y la infeliz reclusa de las tradiciones de su pueblo, asustada
ante el porvenir, y mientras llega el momento del matrimonio, se consuela
con la lectura, y devora las novelas francesas que llenan los escaparates de
las librerías de la gran calle de Pera.
Sus autores favoritos son los mismos de las damas europeas; novelistas
elegantes y discretos que creen en Dios y sólo describen personajes con
buenas rentas, faltos de ocupación y dedicados al amor. La pobre turca
admira á la duquesa rubia y espiritual, que en cada capítulo luce un traje
nuevo de Paquin ó de Doucet; se crispa con los dulces diálogos entre ella y
el conde ó el artista de moda; se conmueve ante las «crisis de alma» que
obligan á la noble señora á cambiar de amante todos los años; la sigue
palpitante de emoción cuando á la caída de la tarde va cautelosa al estudio ó
á la garçonniére de su nuevo ídolo, cubierta con espeso velo (lo que llaman
los grandes modistos velo de adulterio); desfallece con la descripción de los
sabios besos, en el saloncito caldeado discretamente por la chimenea, sobre
cuyo mármol hay rosas, muchas rosas, como es de ritual en toda cita
novelesca de personas que se respetan... y la pobre turquita acaba por
abandonar el libro sobre sus rodillas, y queda con sus ojos de gacela
pensativos y lacrimosos.
Esa es, indudablemente, la vida de las europeas: no puede ser otra, pues
todos los libros dicen lo mismo. Ella sabe inglés y francés; ella toca en el
piano cosas sentimentales; ella hablaría tan bien como la duquesa y la
sentaría igual ó tal vez mejor el misterioso velo de la caída de la tarde. ¡Y
tiene que acabar su vida en un harem, murmurando con las esclavas zafias y
el eunuco negro, de risa infantil! ¡Y todos sus viajes serán al Bósforo
asiático, ó cuando más á Brussa, en el mar de Mármara! ¡Y el conde de sus
ensueños, el artista de complicadas pasiones, será un señor con el fez
eternamente calado, que vivirá en una mitad de la misma casa ocupada por
ella, que entrará y saldrá por distinta puerta, que tendrá diferente
servidumbre, como si fuese un huésped, y sólo una ó dos veces por semana
vendrá á tomar con ella varias tazas minúsculas de café, y fumará cigarrillo
tras cigarrillo, pensando en el último gesto del Gran Señor y en las intrigas
del Yildiz Kiosk!...
La virgen musulmana siente que un impulso de rebeldía rompe la costra
de su mansedumbre oriental, y tiende sus brazos con un crispamiento de
inmensa angustia, como si llamase en su auxilio el misterioso poder que
convierte en paraíso la tierra maldita del Profeta, donde viven los giaoures.
—¡Oh Europa!... ¡París! ¡París!
Algunas, más audaces ó afortunadas, llegan á consumar la rebeldía. Las
hay que han conseguido librarse por procedimientos novelescos de esta
tierra, donde para entrar y salir se necesita pasaporte. Viven en el Paraíso
soñado, en París, y repiten á la inversa la afición poligámica de sus
ascendientes. En Constantinopla nadie quiere hablar de esto, como no sea
para negarlo. El Gran Señor sufre enormes disgustos con estas fugas.
Hace poco tiempo, en un mitin feminista de Suiza, al que asistieron
mujeres de todas las naciones, subió á la tribuna una joven de ojos
orientales, que hablaba con facilidad varios idiomas, y se expresó con
reconcentrado odio contra la tiranía masculina.
Era una parienta del sultán fugada del harem imperial.
*
**
En Turquía todavía existe la venta de esclavas.
Yo quise cándidamente ver un mercado. No existe mercado. Desde que
Inglaterra y otras potencias intervinieron en la vida interna de Turquía, se
acabó la trata de esclavas. Los antiguos caravanserrallos, enormes posadas
de vastos claustros donde hace cincuenta años se exhibían libres de velos
los lotes de carne juvenil llegados de la Circasia, sólo están ocupados hoy
por mercaderes de Trebisonda y Bagdad, que fuman su narghilé exhibiendo
pacientemente los rollos de tapices y los cofrecitos repletos de piedras
preciosas.
Las esclavas se guardan y se venden en las casas de los particulares.
Todo turco á la antigua tiene una irresistible tendencia á la mercadería de
carne femenil. Es una afición atávica heredada de sus ascendientes,
invasores de reinos y bandidos del mar. Cuando un personaje de Stambul
tiene un crédito por cobrar en las provincias de Asia, las más de las veces le
paga éste con una pareja de niñas flacas, mal comidas, pero de espléndidos
ojos, que á su vez ha adquirido de los padres, míseros montañeses de la
Georgia.
Las pequeñas sirven de criadas de lujo en la casa de Stambul, hasta que
la pubertad empieza á hinchar sus formas y el señor propone la mercancía á
sus conocidos, verificándose la venta amigablemente, sin intervención
alguna de los representantes de la ley.
Cuando se visita la morada de un turco á la antigua, salen á vuestro paso,
en el departamento de los hombres, pequeñas niñas sin velo, con anchos
calzones y la trenza colgando sobre la espalda, que os toman el sombrero y
el bastón, dándoos la bienvenida como si fuesen hijas del dueño. Son las
esclavas que esperan su hora para ser vendidas ó que acaban por pasar al
harem del señor convertidas en esposas.
Las agentes de carne conocen las casas donde existen géneros, y todos
los días hacen sus negocios. No sólo venden para los ciudadanos ricos de
Constantinopla y de todos los vilayetos de Turquía, sino que mantienen
negocios continuos con clientes de Egipto, Túnez y Marruecos. La
circasiana y la georgiana siguen siendo, como en otros tiempos, el adorno
elegante de todo harem respetable, y el género, impulsado por una continua
demanda, parece multiplicarse con arreglo á las exigencias.
Ningún miedo acerca del porvenir, ningún terror futuro se transparenta
en la límpida mirada de estas hermosas bestiezuelas, delgados capullos que
esperan para esparcirse la tibia y cerrada atmósfera del harem. Son esclavas
porque han costado dinero á los dueños, pero su suerte es igual á la de todas
las mujeres turcas que nacieron libres. Siempre las compra algún otomano
viejo, para unirlas al batallón de sus antiguas esposas ó para darlas á un hijo
tan joven como ellas. Por poca influencia que ejerzan sobre el dueño, éste
las convierte en mujeres legítimas, deseoso de establecer cierta igualdad
entre sus hembras, medio seguro para conseguir en la casa una paz relativa.
Muchas sultanas comenzaron siendo esclavas.
Los precios de estos animalillos de lujo, que viven alegres con una
inconsciencia infantil hasta los días de la vejez fumando rubios cigarrillos
en un diván, tragando confituras y haciendo danzar las babuchas amarillas
sobre los pulgares de sus pies sonrosados, varían según los méritos del
género.
Una muchacha defectuosa y de miembros secos puede adquirirse por
quinientas pesetas. Las de buena dentadura, largo pelo, ojos grandes, y que
prometen ensancharse de formas, hasta llegar á una gordura blanca, firme y
sedosa, valen dos mil ó dos mil quinientas.
Un caballo turco, de escasa alzada, largas crines, cabezón y con
inquietos remos, cuesta mucho más.
*
**
Los eunucos son más caros.
En realidad no sirven para nada. Son seres de lujo, signos de poder y de
riqueza para el amo. Equivalen á los lacayos que se exhiben majestuosos en
los pescantes de los coches de Europa. Estorban al cochero las más de las
veces, se pasean sin que los dueños necesiten casi nunca de sus servicios,
molestan con su presencia estirada y solemne, pero ninguna persona rica
puede pasarse sin ellos.
En otros tiempos, el turco celoso confiaba en la vigilancia de su eunuco,
feroz guardador de las mujeres. Hoy es escéptico, sabe que estos hombres-
hembras, por un irresistible impulso de su naturaleza neutra, aunque riñan
con la mujer por celos femeniles acaban entendiéndose con ella y
prestándose á toda clase de tercerías. Sin embargo, el eunuco negro sigue en
favor, como una manifestación de poder y de riqueza. Es algo así como el
blasón de armas de la casa, y los señores rivalizan en tenerlos agasajados y
bien vestidos. Un harem no puede salir á la calle si no marcha escoltado por
un par de eunucos de señorial aspecto. Cuando las mujeres van en carroza,
los negros trotan junto á las portezuelas, jinetes en los mejores caballos del
amo. Si de noche sale el rebaño femenil á hacer visita á otro harem, ellos
marchan á la cabeza, por las solitarias calles de Stambul, garrote en mano y
con grandes farolones que trazan en el camino una danza de pálidos
resplandores y gesticulantes sombras.
El eunuco es el administrador que corre con los gastos de la casa; el
intermediario obligado entre las esposas y el marido. El da el dinero para
las compras, regatea con las mujeres, se muestra quisquilloso, avaro y
gruñón, como no lo es nunca el turco. El esclavo chilla á las señoras, las
empuja, es un gallo sin cresta que picotea continuamente á las habitantes
del gallinero, y éstas, que temen sus delaciones y su malhumor, lo acarician
como un niño grande, y acaban por reirse de él.
Sólo el sultán y los grandes personajes de la corte tienen un numeroso
cortejo de eunucos. Los turcos de cierta posición se contentan con dos ó con
uno solo.
Un eunuco cuesta casi una fortuna, pues escasean mucho.
Antes se fabricaban con mayor facilidad, y la abundancia rebajaba los
precios.
En esta monstruosa deformación del hombre, ha habido sus modas. El
arte de formar el eunuco ha progresado, pero extremando su crueldad. El
refinamiento del turco en sus sospechas y sus celos, ha sido fatal para estos
infelices negros, lúgubres mamarrachos, enormes como colosos, de rostro
fiero, y con una vocecilla estridente y crispadora, semejante al chasquido de
una caña que se rompe.
Antes les bastaba para cumplir su oficio con verse libres de las preciosas
superfluidades cuya ausencia motiva, según dicen, la angélica voz de los
cantores del Papa.
Pero algo quedaba en ellos, después de la monda, que constituía un
motivo de perpetua alarma para los señores turcos. La mujer, ociosa y triste
en el encierro, discurre mil diabluras: la eterna presencia del eunuco, único
hombre compañero de clausura, la inspiraba según parece los más refinados
ardides. Y echando mano á lo que aun podían encontrar, las malditas
pasaban horas y horas recreándose en un entretenimiento sin fin, tranquila
la conciencia porque no aumentaban ilegítimamente la prole del señor, pero
faltando á la fidelidad descaradamente en el sagrado del hogar.
Los turcos, escamados por estos abusos, extreman actualmente la
humana poda. Sobre los pobres negros, guardianes del honor, se abate una
furia semejante á la de los leñadores de bosques vírgenes, que nada
perdonan, echando abajo ramas y tronco. Su obscura piel es campo roturado
y liso, en la que no queda el más leve rastro de frutos humanos.
La espeluznante operación la realizan los crueles fabricantes en negros
de pocos años, allá en los arenales de Africa. Los cuerpos los hunden en el
suelo hasta la cintura, y así permanece el operado semanas y meses, entre
sus verdugos que le cuidan y le alimentan, hasta que la arena cicatriza la
cuchillada atroz ó se les va por ella la sangre y el alma.
El noventa y cinco por ciento de los eunucos muere tras la cruenta
amputación.
Por esto los que quedan son personajes poseídos de su importancia,
influyentes en la vida turca, caprichosos é irresistibles, lo mismo que una
tiple que se considera indispensable y precisa.

XXIX

Los derviches aulladores

En la orilla asiática de Constantinopla, entre el barrio puramente turco de
Scutari, en el que no vive ningún europeo, y el cementerio que lleva el
mismo nombre, vasta extensión bordeada de kioscos funerarios y
sombreada por plátanos seculares, está la mezquita del Roufat, donde todos
los jueves, á las dos de la tarde, celebran su ceremonia religiosa los
derviches aulladores.
Esta mezquita no es grande y luminosa como la de Eyoub, donde los
derviches danzantes voltean, como flores, sus pesadas faldas. La secta de
los aulladores es sombría y feroz, y parece guardar en sus extraños ritos el
alma fanática é implacable del antiguo turco, terror de Europa. Una sala
baja y casi obscura, con el techo sostenido por columnas de madera, y
desnuda de todo adorno arquitectónico, es el lugar de la ceremonia. En las
paredes, algunos cartelones, con versículos del Korán, y unos negruzcos
panderos. Sobre el tapiz que cubre el Mirab, una panoplia de armas
antiguas, turcas é indias: espadas onduladas, cimitarras venerables, hachas
de curva entrante y mazas erizadas de clavos.
Sobre la piel de cordero tendida en este sitio de honor, se sienta, con las
piernas cruzadas, el imán, el gran sacerdote de los derviches aulladores, que
ostenta en su turbante blanco la arrollada faja verde de los que se tienen por
descendientes del Profeta.
Este imán es un árabe que goza de gran popularidad, aparte de su poder
de hacer milagros, por ser el hombre más hermoso de Constantinopla. No
he visto tipo más perfecto de la belleza semita. De regular estatura, parece,
sin embargo, muy alto, por la gallardía de su cuerpo enjuto y ágil, en el cual
el esqueleto sólo está revestido de los tejidos indispensables para la vida.
Las facciones son de un moreno brillante, entre rojizo y verdoso; el mismo
tono de los bronces florentinos. La nariz, aguileña y fina, avanza sobre una
barba clara y rizosa, de un negro azulado, y los ojos, enormes y misteriosos,
tienen una veladura de color de tabaco en sus córneas, que hace resaltar el
fuego de las luminosas pupilas. Es un jinete de los desiertos arábigos, un
pirata del mar de arena, un caballero andante de las soledades asiáticas,
majestuoso y melancólico, que se ha dedicado á sacerdote y vive en la
civilizada Constantinopla, rozándose con los europeos.
Las viajeras que ocupan las galerías de la mezquita contemplan con
admiración á este Apolo árabe; pero él permanece inmóvil en la piel de
cordero, envuelto en su sotana negra, por cuya abertura luce un rico chaleco
de seda, de rayas menudas y multicolores. No sé por qué presiento que el
jefe de los derviches aulladores, que forman la cofradía más fanática de
Constantinopla, es un hombre enterado, sin ninguna fe en las ceremonias
que preside. Tiene la expresión demasiado inteligente para creer en tales
cosas. Un día, hablando de él con Constans, el embajador de Francia, éste
rompió á reir, con la irreverencia de un viejo republicano:
—Le conozco mucho. Un blagueur. Lo que ustedes llaman un guasón.
Un hombre inteligente que se amolda á las circunstancias.
Pero aunque este árabe majestuoso engañe á los suyos, no teniendo fe en
los mismos ritos que ejecuta, hay en sus actos una gran nobleza. Es un buen
turco, que cree necesario para la vida de su pueblo el mantenimiento de las
tradiciones, y las sigue con solemne gravedad, sin creer en ellas.
Frente á él están los derviches, formados en fila, llevando sobre la
cabeza, como distintivo de la cofradía, un solideo de fieltro, semejante á
media corteza de coco. Unos son negros, medio desnudos, de lanuda
cabellera y ojos diabólicos; otros, blancos, que conservan el traje de calle y
parecen tenderos del inmediato barrio de Scutari.
Todos ellos repiten á coro una especie de letanía monótona, y balancean
su cabeza adelante y atrás, como si estuviera muerta sobre los hombros,
doblando al mismo tiempo el cuerpo por la cintura. Este vaivén continuo,
acompañado de un canturreo semejante al de los niños en la escuela, acaba
por dar una especie de vértigo. El sudor rueda por el cuerpo de los negros,
cubriéndolos de una capa húmeda y goteante. Los blancos pierden por
momentos su correcto exterior de burgueses. Los cuellos de camisa se
arrugan y ennegrecen como trapos; las corbatas se esparcen deshechas; las
cadenas de reloj saltan locas sobre el vientre, como si fuesen á romperse.
«¡La Ilah il Allah!», cantan los derviches con un furor creciente,
extremando su loco vaivén de muñecos mecánicos, y el gran sacerdote los
contempla inmóvil, como un maestro que preside su escuela, y cuando el
movimiento parece debilitarse, hace una imperceptible señal á uno de sus
acólitos, encogido junto á él, y éste grita y palmotea para acelerar el curso
de la oración.
Formando una larga cadena, y apoyado cada uno en el hombro del
vecino, los derviches se mueven, como un péndulo humano, á un lado y á
otro, con monótona regularidad. Este balanceo, y la repetición monótona de
su plegaria, parece embriagarles. Unos tienen los ojos casi salidos de las
órbitas, con una expresión feroz. Otros los cierran, como si estuviesen
dormidos, moviéndose y cantando en pleno ensueño. Los derviches
empiezan á justificar su título de aulladores. La letanía se corta con gritos
estridentes, verdaderos ladridos, que espeluznan de horror á los
espectadores europeos. La movible cofradía semeja una aglomeración de
fieras amaestradas. Sus voces no tienen ya nada de humano. Hay momentos
en que parece que van á saltar las barandillas para morder á los occidentales
curiosos, agrupados detrás de ellas.
De pronto, un golpe ensordecedor sobre la madera del pavimento. Un
cuerpo que se desploma. El auditorio se estremece como ante la caída de un
cadáver. Es un negro grande y enjuto, cubierto de sagrados harapos, que se
revuelca en el suelo con los miembros torcidos, la boca espumosa y los ojos
en blanco por un estrabismo loco. Según cuentan, este negro, que dentro de
la mezquita parece un mendigo fanático, es capitán de caballería en el
ejército del sultán. De su pecho oscilante sale un rugido, que es al mismo
tiempo una queja de dulce agonía. ¡Allah hou!... Y en la crispación de su
rostro lustroso, en su mirada completamente blanca, hay algo de éxtasis,
como si contemplase á su Dios asomando entre esplendores de oro sobre las
tiendas celestiales, en cuyas aberturas aguardan las huríes de redondas
formas y húmedos ojos á los guerreros fieles del Profeta.
Tras el negro cae otro derviche, y luego otro. Ruedan sobre el
entarimado los cuerpos, convulsos por la embriaguez hipnótica, lanzando
aullidos espeluznantes. Las viajeras occidentales huyen desfallecidas,
ocultando los ojos en el pañuelo, sintiendo que ellas también van á
desplomarse á impulsos del excitado histerismo de su sexo; y mientras
tanto, los derviches que aun se mantienen de pie se agitan cada vez con
mayor ímpetu y desfiguran sus voces hasta convertirlas en ladridos.
Cerca de una hora dura esta pesadilla feroz, esta escena que parece de
otro mundo.
Al fin, el gran sacerdote se mueve, hace un gesto y se rompe la fila de
los derviches. Los que aun se mantienen de pie salen de la sala con paso
vacilante, en pleno vértigo, para ir á secarse el sudor y tomar aliento en una
pieza vecina. Los que están inertes en el suelo, como si durmiesen, son
sacados á brazos.
Un ayudante del gran sacerdote entra en la mezquita llevando de la mano
larga fila de niños y niñas. Todos se arrodillan ante el imán, esperando el
momento de la curación. Vienen de los barrios más apartados de
Constantinopla, han pasado el Bósforo, para llegar á la mezquita de los
derviches aulladores. El gran sacerdote, descendiente del Profeta, venido de
la misteriosa Arabia, donde reside toda sabiduría, cura con el soplo de su
aliento y el contacto de sus pies. Unos á otros se transmiten, con el alto
sacerdocio, este divino poder. Esto lo saben desde el sultán hasta el último
hamal de los muelles del Cuerno de Oro.
Las criaturas se tienden boca abajo en el suelo de la mezquita. El
hermoso imán se yergue despojándose de las babuchas, y apoyado en uno
de sus ayudantes camina lentamente sobre los riñones de las criaturas. Poco
debe pesar el enjuto y esbelto árabe, pero aun así parece imposible que no
revienten estos cuerpecillos, que forman un pavimento animado bajo sus
pies. ¡El noble y sereno gesto de resignación del hermoso sacerdote! ¡Su
triste gravedad al volver á repasar sobre los cuerpos de los pequeños!...
Éstos se levantan, se sacuden, salen riendo y empujándose, como
criaturas acostumbradas á venir todas las semanas, y para las cuales el viaje
es una verdadera fiesta. No presentan ninguna enfermedad exterior. Parecen
sanos y robustos. Sus padres quieren curarlos de embrujamientos é
inapetencias, males de los que triunfa casi siempre el santo imán... con
ayuda del tiempo. Después se prosternan ante él, implorando la huella de
sus pies, hombres de todas clases; viejos cargadores, soldados y marineros.
Cerca de mí está sentado un joven turco, elegantemente vestido á la
europea, con alto cuello, vistosa corbata y un gabán inglés á rayas. El fez es
lo único que delata su nacionalidad. Tiene cara de alegre vividor, falto de
escrúpulos; sus ojos son de fría insolencia; en su rostro lleva marcas
recientes de enfermedades irrevelables. ¡Cómo reirá este turco
ultramoderno de la credulidad de sus compatriotas!...
El imán, ocupado en marchar sobre los riñones de los fieles, lanza
rápidas miradas á unas celosías tras las cuales se adivina cierta agitación,
acompañada de sordo zumbido. Son las damas turcas que se impacientan.
El sacerdote debe subir para la curación de las enfermas en una pieza
aparte.
Acurrucado en la piel de cordero, se prepara á hacer su oración ante el
Mirab antes de partir, cuando llega el último enfermo. Es el joven turco
vestido á la inglesa, el elegante del gabán rayado, que se arrodilla
compungido, brillantes de fe los audaces ojos.
El imán escucha con un gesto de inmensa misericordia la corta confesión
de sus pecados y enfermedades. Le abraza, le sopla varias veces en los ojos
y en la boca, sin perder su noble gravedad, y luego pasa varias veces sobre
él, manteniéndose derecho en sus riñones con la calma de un filósofo,
convencido de que la humanidad cobarde quiere ser engañada en sus
dolores, y que la mentira es buena cuando puede servir de consuelo.

XXX
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebookball.com