Skip to main content

Prototyping Security Applications for Ambient Intelligence

Researcher: Radu Marculescu


Prototyping Security Applications for Ambient Intelligence

This work has the origin in the project “Design Methodologies for Security Applications Targeting Ambient Intelligence” funded through CyLab during 2004-2005. The main idea of that project was to explore the design space of electronic textiles running security applications. Energy, memory and computation power limitations, on one hand, and high failure rates of the components, on the other hand, necessitate robust parallel implementations. Therefore, we decided to use the concept of “network” as the implementation paradigm and explore the possibility of a distributed implementation of the AES algorithm.

Building upon these preliminary results, in this new proposal we plan to build a prototype as a demonstrator of our ideas. Due to limitations in size, battery lifetime and ultimately, cost, mapping complex video applications onto resource constrained systems is a very challenging proposition. Adding feature-rich multimedia to the ambient intelligence paradigm results in significantly more stringent requirements to be met in terms of dependability, enhanced security, and interactive entertainment compared to today’s portable and stationary multimedia devices.

The target system we envision consists of an array of cameras inconspicuously embedded in the environment such as the walls of a conference room or office. The system is organized in a hierarchical manner at two levels of abstraction: the node-level and the network-level (Figure 1(a)).

Figure 1 – (a) Ambient multimedia system and (b) smart video surveillance system

Each node consists of a video camera and one or more simple microprocessors which process the raw data captured by the camera and cooperate with each other to accomplish video-based object-tracking. Detailed information such as position, direction and velocity of the moving object is collected to assist the network-level management, which consists of transferring the task of object-tracking from one node to another as an object moves from one side of the video frame to the other. While last year’s project focused primarily on the design issues that occur at node-level, the proposed work herein is envisioned mostly for the overall network design.

A potential application of the intelligent object tracking is a smart video surveillance system (Figure 1(b)). In this system, the camera captures video data in its focus area, and sends it to both the video encoding software and the object tracking software, which may run on different computing devices. The software tracks the objects in the video, and sends commands to the motor controller which, in turn, activates a motor which changes the focus direction (or angle) of the camera. An important thing to note is that the object–tracking application lies at the very basis of many video-based security applications which we can readily consider later.

Figure 2 – (a) Region of interest video data processing and (b) data partitioning for a vertically partitioned video frame

To map object tracking to resource-constrained nodes, we first consider a technique of defining a window within a video frame, and only operating on the data inside that window, ignoring the rest of the frame (Figure 2(a)). By using this lossy technique, the processing requirements can be reduced by roughly 90% while the error introduced in the quality of the results is roughly 10%. The other technique is adaptive data partitioning combined with a content-based power management algorithm (Figure 2(b)). By distributing video processing among multiple processors and shutting them down when they are not needed, the energy consumed per processor can be reduced by 70% without sacrificing the performance of the underlying video-based application.

The main features that make this prototype unique and relevant to Cylab are:

  • At node-level: In a single chip multiprocessor setup (i.e. Network-on-Chip design), explore the networked implementation of the AES algorithm working together with an image processing application (e.g. JPEG). Such an implementation can be very useful for exploring efficient ways to map highly intensive video processing applications onto resource constrained devices which are characteristic to ambient intelligence.
  • At network-level, in the context of video sensor networks, build a small network (10 or fewer video nodes) and explore the issue of securing the environment while using collaborative algorithms to manage dynamic, changing spaces together with video-based object tracking.

 Anticipated impact

Video sensor networks represent an emerging platform with countless applications and profound impact on our life. The design methodology we plan to develop can be utilized to explore the design space for efficient implementation and guide the design process based on precise design metrics and cost functions. The resulting implementations will be faster, lower power, more fault- and attack-tolerant compared to the ad hoc solutions generated without such a methodology. The design methodology applied to the object–tracking application in this proposal can be readily extended to other video-enhanced security applications which will then also benefit in the same way.

Figure 3 – (a) Omnivision camera and (b) Distributed implementation of AES using Xilinx Virtex II FPGA

So far, we have explored the design of an individual video node built with an Omnivision compact camera2 (Figure 3(a)), as well as a distributed implementation of AES based on Xilinx Virtex II FPGA3 (Figure 3(b)). Compared to the standard mesh architecture, the customized architecture in Figure 3(b) shows about 36% throughput increase and 51% reduction in the energy required to encrypt 128 bits of data for the AES algorithm. This first-hand experience places us in the ideal position for successful prototyping such a surveillance network.

Proposal: Trust-Free Garbage Collection for Mobile Code

In today's networked world, mobile code is all around us. Increasingly, our information infrastructure relies on code that is installed or updated in real time on devices for which downtime cannot be tolerated. This arrangement poses considerable security challenges, and those challenges are certain to grow as network-attached devices and other shared configurable systems become more ubiquitous. In most cases, these challenges are addressed today using what we may call extrinsic verification. Typically, the producer of a mobile software component will sign it, thereby making it possible for any device to verify that the component indeed was produced by the person or agency claimed. That person or agency is trusted to have implemented to component correctly and benignly, and therefore it may be safety installed.

This model of certification is “extrinsic" in the sense that it says nothing about the code itself, only about its producer. Extrinsic certification works satisfactorily today, but it is fundamentally unscalable. We cannot expect that all the mobile code we use will be produced by a small number of trusted authorities. Rapid growth in the software industry, in the open source movement, and in the prevalence of end-user programming is leading to an explosion in the number of software producers. Moreover, even trusted software producers have been known to make mistakes.

To achieve scalable and robust security in the presence of mobile code, we must move to intrinsic verification, wherein security is assured by mechanically inspecting the code itself. Intrinsic verification is scalable and robust because there is no need to trust anyone but the developers of the verification tools. Intrinsic verification is implemented in a variety of systems, including Java, Proof-Carrying Code, and Typed Assembly Language. Each of these systems is based on the observation that verifying safety unaided is too hard, and therefore the code producer should some information to assist the verifier. This information, which we will call a certificate, is tantamount to a machine-readable proof of safety. A software component accompanied by such a certificate is referred to as certified code.

All the certified code systems developed to date share one significant weakness: none of them allow certified software to manage its own memory. In most cases these systems mandate the use of particular trusted code to allocate memory and collect garbage. (Other systems impose even more severe restrictions, such as disallowing dynamic allocation entirely.) This is unfortunate, as not all applications are suitable for garbage collection, and even those that are may want to use a collector tailored for their own application, or simply a collector more modern than was available when the certified code system was deployed. Thus, the future of scalable mobile code is likely to require the ability to certify memory management code for safety. However, the technical obstacles are such that no one has yet succeeded in certifying the safety of any remotely practical garbage collector.

Proposed Work

The proposed research will develop technology for practical trust-free memory management. Since garbage collectors are the most technically challenging memory managers to address, the proposed research will focus on type-safe garbage collection. In particular, it will develop a low-level type system for memory management code, implement in it at least one practical garbage collector suitable for use with high-level garbage-collected languages such as ML and Java, and deploy the collector in a grid computing setting.

Most prior work on type-safe garbage collection  (but not all) has been based on high-level primitives tailored for garbage collection and on type structure designed to support those primitives. We agree that type theory is the right framework in which to consider the problem, but we suggest that it is profitable to begin at a very low level.

Type systems based on high-level GC primitives face two opposing pressures: They must be simple, because complicated type systems are difficult to use. On the other hand, their nature makes them complex, because they must internalize the complex invariants on which the primitives depend, and secondly, because they must provide invariants for all phases in a single type system. The need for simplicity limits the degree to which the type system can grow to provide more powerful GC primitives. Existing work has yet to produce a practical typed collector.

Instead, we propose to begin at a low level with a simple but powerful proof system in which it is possible to encode the invariants of a practical collector. Thus, GC invariants become part of the program (as they should be), rather than part of the type system. Moreover, there is no need to deal with invariants for distinct phases at the same time; each phase may state its own invariants.

The proposed effort will proceed in three stages:

  1. We will develop a type system, based on linear logic, suitable for the implementation of low-level, memory-managing code, particularly garbage collectors. This type system will provide sufficient expressive power to state the invariants of practical collectors, and show that those invariants are maintained through execution. Naturally, we will show that well-typed programs must be safe. A tentative design of the type system, called the Linear Safety Logic (or LSL), is now complete. 
  1. LSL is very low-level and does not presuppose any programming idiom. Therefore, to obtain safety, each instruction incurs a proof obligation. This makes LSL very flexible, but it also means that simple tasks incur significant proof obligations. Consequently, we expect that applications more substantial than our proof-of-concept will require tools to facilitate code development. An automated proof assistant is now under development. We expect to tie this proof assistant into a certifying compiler for at least one higher-level language.
  1. We will implement a practical, type-safe garbage collector in LSL using the tools discussed above. We will begin with a proof-of-concept collector based on reference counting. Then we plan to continue with a prototype collector implementing a conservative mark-sweep algorithm but omitting most optimizations of modern, tuned collectors. Finally we will add such optimizations as are feasible.