systems, they may
or may not be in secure enclosures. Again, the security here is similar to that
of any physical good, and we have to consider not only the goods themselves
(the computers, in one form or another) but also their environment: network
links, power supply, temperature control, and the like.
The
most interesting case, as far as this book is concerned, is the personal
electronic device. Being a small item that accompanies us, it is subject to
loss, and therefore its physical security cannot be assumed. As we saw, there
are two kinds of personal electronic devices, those with a rich environment
surrounding a personal core, like, say, a cellular phone, and those reduced to
the personal core, for example chip card for banking. A full-featured personal
electronic device is a consumer item, and its cost must be controlled
accordingly. For that reason, there are few secured personal electronic devices
outside of the military. Typically, the personal electronic device relegates
security matters to its trusted core. So, in effect, all personal electronic
devices, whether full-featured or bare, end up using similar secure cores. And
a secure code must indeed be protected, because it contains the data that are
most close to us, whether they are related to our identity, our beliefs, our
health or our money. The physical security features of trusted cores are
numerous, and we’ll expand on them in the next chapter. Simply, we need it to
be clearly established that trusted cores are physically protected, and that we
can count on that protection when devising applications related to the use of
personal data on the network.
Finally,
we must acknowledge a limitation of trusted cores in terms of physical attributes.
Trusted cores need to be as simple as possible, because with complexity come
security gaps, and they need to be inexpensive, so that they can be used
everywhere. This necessarily means that they will have limitations in size, in
speed, and accordingly in their response time. That’s why personal data may
actually not be all in the trusted core. In some cases, they will be outside of
the trusted core, either on a full-featured personal electronic device, or say,
on the network somewhere. As those locations are not necessarily secured, the data
themselves need to be protected by cryptographic means, which themselves are
enabled by the trusted core. For example, a complete encrypted text can be
freely available on the network, but if a trusted core is needed to decode it,
it’s of no use to steal it; it’s protected. In reality, the situation can get
very rapidly complex, because in some cases we want to secure in the trusted
core only particular pieces of data residing on the network, or some time we
just want to use the trusted core as repository for the decoding keys of the
data. In the former case, the trusted core may have to be very sophisticated,
since we may want it to process the secure part of the data while the full
stream of data itself is processed by a general computer. In the latter, we may
have a simpler trusted device: that’s the case of the Trusted Platform Module,
the trusted core found on the circuit board of laptops.
Wherever they
are, if they cannot be accessed physically, data may be accessed logically,
i.e., via the network. For that reason, much of the work on computer security
is focused on access methods, which are encompassing three domains, named authentication,
authorization and accounting. Whereas, as we’ve said earlier in
our discussion of content, there is no full-fledge theory of content that we
know of and ours is but a beginning, there is, in comparison, a strong body of
work and formalism around access methods and practices. We will then draw on a
particular specification of authentication, called SAML (Security Assertion
Mockup Language), and on a particular specification of authorization, called
XACML (eXtensible Access Control Markup Language), for presenting access
concepts and their implementation. Wherever SAML or XACML are lacking, we’ll
supplement the discussion with input from other, possibly competing
|