Extensible Access Control Markup Language

XACML is an XML specification for expressing fine-grained information access
policies in XML documents or any other electronic resource.

At configuration time, XACML expresses and communicates the rules and policies
that an access-control mechanism uses to derive an access decision for a set of
subjects and attributes. By comparison, at run time SAML formulates assertions
about subjects, their attributes, and their access rights. For digital rights
management or workflow processing use cases, an application or medium can
transmit XACML rules together with the content to which access is being regulated.
If necessary, mechanisms outside XACML must but be used to enforce the
integrity of access rules and confidentiality of content.

The XACML specification defines ways to encode rules, bundle rules to policies,
and define selection and combination algorithms in cases where multiple rules and
policies apply.

Access control lists in XACML are 4-tuples—subject, target object, permitted
action, provision. The subject can include user IDs, groups, or role
names. The target object allows granularity down to a single XML document
element. The permitted action primitive can be either read, write, create, or delete.
This represents a major XACML limitation because it does not accommodate
domain-specific permission types. A provision is an action that must execute
upon a rule’s activation (for both deny and grant rules). Such actions may include
initiating log-in, requesting additional credentials, and sending an alert. The
XACML specification defines a language for formulating such provisions.

XML API and Application Support

DB2 introduced a new SQL column type in the database, the XML data type.
Applications can bind various language specific data types for input and output
of XML columns or parameters. These existing language specific data types
only allow the user to work with XML as character or binary types.

In order to use XML efficiently and seamlessly, new language specific XML
types are added to the existing client interfaces. These new language specific
XML types enable the database to be more efficient and enable the database
to supply a richer API for the applications. By making XML explicit in the
application, the database will avoid unnecessary and/or unwanted code
page conversions. XML documents have an internal encoding declaration
which makes all but the XML parser’s transcoding unnecessary. Avoiding
unnecessary code page conversions is often an important performance
benefit. Additionally, transcoding an XML document without carefully
adjusting the XML encoding declaration might make the XML document
invalid.

All the major database interfaces are supporting the XML type natively, i.e.
treating XML data as XML, not as a character type. Below, we will touch
on JDBC, ODBC, .NET, and embedded SQL.

Domain specific middleware for Distributed Real-time and Embedded Systems

Domain-specific middleware services are tailored to the requirements of particular
DRE system domains, such as avionics mission computing, radar processing, online
financial trading, or distributed process control. Unlike the previous three middleware
layers—which provide broadly reusable “horizontal” mechanisms and services domain
specific middleware services are targeted at vertical markets. From both a COTS and
R&D perspective, domain-specific services are the least mature of the middleware
layers, due in part to the historical lack of distribution middleware and common
middleware service standards needed to provide a stable base upon which to create
domain-specific middleware services. Since they embody knowledge of a domain
however, domain-specific middleware services have the most potential to increase the
quality and decrease the cycle time and effort that integrators require to develop
particular classes of DRE systems.

An example of domain-specific middleware services R&D that is relevant for DRE
systems is the Boeing Bold Stroke architecture, which has been used as the open
experimentation platform on many DARPA ITO programs. Bold Stroke is an open
architecture for mission computing avionics capabilities, such as navigation, heads-up
display management, weapons targeting and release, and air frame sensor processing.
The domain specific middleware services in Bold Stroke are layered upon COTS
processors (PowerPC), network interconnects (VME), operating systems
(VxWorks), infrastructure middleware (ACE), distribution middleware (TAO), and
common middleware services (QuO and the CORBA Event Service).

SECURE EMBEDDED SYSTEM DESIGN

Our experiences with personal computers and the Internet have clearly identified information security as a paramount challenge. Embedded systems, which are used pervasively in our lives, now contain our sensitive personal data, identity, and even our purchasing power, and perform several safety-critical functions. Some examples include mobile phones, MP3 players, automotive electronics, medi-cal appliances, and ubiquitous devices such as sensors and RFID tags. Unless embedded system security is adequately addressed, it will become a concern that impedes the adoption and usage of many embedded system products, applications, and services.

Several technologies have been developed to address information security (cryptography, secure communication protocols, anti-virus tools, firewalls, intrusion detection, and so on), which can be adapted to embedded systems. These technologies can be referred to as "functional" security meas-ures, since they usually specify functions that must be added to the target system without any consid-eration of how they are embodied in hardware or software.

However, they are hardly sufficient to ensure the security of embedded systems in practice. Most real security attacks do not directly take on the theoretical strength of cryptographic algorithms; instead, they target weaknesses in a system's "implementation". Moreover, embedded-system designers have to cope with security as yet another requirement, in addition to performance, power, cost, etc.

We will present an introduction to embedded system security challenges, and argue that ef-fective security solutions can be realized only if they are built-in at various stages of the design process (architecture, HW design, and SW development). The objectives of secure embedded system design will be defined from the designer's perspective as addressing various "gaps" such as

1. the assurance gap, which refers to the gap between functional security measures and truly secure implementations,

2. the security processing gap, which arises due to the processing requirements of the additional computations that must be performed for the purpose of security, and

3. the battery gap, which is a consequence of the energy consumed in performing security-related functions.

We will provide an overview of our research in this area, covering both embedded system architectures that address these gaps, and methodologies that assist in their design. We will use mobile appliances (mobile phones, PDAs) to illustrate secure embedded system design challenges, and describe MOSES, a security platform that we have developed and deployed in NEC's next-generation mobile phones.

Sensor Networks and its Node tracking scenarios

The tracking of a tagged object through a region of space monitored by a sensor
network. There are many situations where one would like to track the location
of valuable assets or personnel. Current inventory control systems attempt to
track objects by recording the last checkpoint that an object passed through.
However, with these systems it is not possible to determine the current location
of an object. For example, UPS tracks every shipment by scanning it with a
barcode whenever it passes through a routing center. The system breaks
down when objects do not flow from checkpoint to checkpoint. In typical work
environments it is impractical to expect objects to be continually passed  through
checkpoints.

With wireless sensor networks, objects can be tracked by simply tagging them
with a small sensor node. The sensor node will be tracked as it moves through
a field of sensor nodes that are deployed in the environment at known locations.
Instead of sensing environmental data, these nodes will be deployed to sense
the RF messages of the nodes attached to various objects. The nodes can be
used as active tags that announce the presence of a device. A database can be
used to record the location of tracked objects relative to the set of nodes at
known locations. With this system, it becomes possible to ask where an
object is currently, not simply where it was last scanned.

Unlike sensing or security networks, node tracking applications will continually
have topology changes as nodes move through the network. While the connectivity
between the nodes at fixed locations will remain relatively stable, the connectivity
to mobile nodes will be continually changing. Additionally the set of nodes being
tracked will continually change as objects enter and leave the system. It is essential
that the network be able to efficiently detect the presence of new nodes that enter
the network.

Bottom-Boot and Top-Boot Flash Devices

Some devices are organized as a few small sectors at the bottom address space,
followed by large sectors that fill the remaining space. Some devices have a few small
sectors at the top of the device’s address space and use large sectors in the lower
address space. Since boot code is typically placed in small sectors, flash memory is
some times described as bottom-boot or top-boot, depending on where the smaller
sectors are located.

Ultimately, one sector contains the memory space that the CPU accesses as a
result of a power cycle or reset (boot). This sector is usually referred to as the boot
sector. Because some CPUs have a reset vector that is at the top of memory space and
others have a reset vector at the bottom of memory space, the flash devices come in
bottom-boot and top-boot flavors. A processor that boots to the top of memory
space would probably use a top-boot device, and a processor that boots to the bottom
of its memory space would be more suited to a bottom-boot device.

When the boot sector of the flash device exists in the boot-time address space of
the CPU, it can be protected by making the boot sectors unmodifiable. Since only a
small amount of code is typically needed to provide a basic boot, there is little
wasted space if you dedicate a small sector to an unmodifiable boot routine. This
supports the ability to make as much of the flash space in-system reprogrammable
without losing the security of knowing that if all of the reprogrammable flash was
accidentally corrupted, the system would still be able to boot through the small
amount of code in the unmodifiable boot sector.

Fuzzy Rules for Large Feature Spaces

Many relevant applications of information mining e.g. analysis of gene expression
patterns inherently deal with high dimensional data. Similarly multimedia data
analysis and multi-relational database mining usually involve dealing with high
dimensional feature spaces.

In addition to that, data fusion and the propositionalization of multirelational
databases, which are essential to accessing data previously unavailable for many
analysis methods, usually produce high dimensional data sets. Although the
number of input variables can sometimes be reduced with preprocessing, it is
necessary to include methods that are robust to high  dimensional input data.
But while large feature spaces have to be searched, interesting relationships in
such data often involve smaller subsets of  variables and can comprehensibly
be represented by fuzzy rules.

Fuzzy rules are easily understood by the users thus fulfi lling their immediate
information needs. The fuzzy rule induction algorithm given in is speci cally suited
to dealing with large feature spaces and heterogeneous data. An advanced
version constructs a hierarchy of rule sets with different levels of complexity.
For instance this approach allows users to assess basic relations with
relatively coarse fuzzy rules while using a higher level of detail for prediction tasks.