Udo Schuermann, John Barkley
June 1998

Security

Users of network-based distributed applications require assurance that their interactions and data are reliable, private, and accessible only to authorized parties. Such assurance is provided by applications which make use of the following security services: authentication, access control, integrity, and confidentiality. This document briefly defines these services, gives an overview of security in general, and then explains how security applies to the Instructional Management System (IMS).

Definition of Terms

Authentication: Both sides engaged in a communication exchange present to each other credentials that allow each to be confident of the identity of the other. In other words, the server computer can be certain of the user's identity, and the user can be certain that the other side is not an impostor.
Access Control: Information is made accessible only to those who are allowed to view it. Some information, such as a user's email address, might be public knowledge, but a telephone number, mailing address, or academic information may be available only to parties who are authorized to view such information.
Integrity: A cryptographic checksum (hash) is attached to information in order to detect whether information has been modified. This service may be used for both stored and transmitted information.
Confidentiality: Information is encrypted in transit so that only authorized parties are able to view it. It will be computationally infeasible for an unauthorized party to intercept, decode, and view the information.

Overview

Effective security depends on the use of the services described above. Information system security depends on the cryptographic algorithms used to implement these services. Since the effectiveness of cryptographic algorithms depends on computing speed, these algorithms lose effectiveness over time as computing speed increases.

The Facets are not Independent

All of the services of authentication, access control, integrity, and confidentiality must be applied to act in concert. Access to information cannot be properly controlled (access control) if the identity of a party cannot be determined (authentication); likewise someone's professed identity cannot be trusted if the identity was established in a way that could have allowed other parties to forge the credentials.

It is clear that implementing merely one or two facets of secure communications leaves open an Achilles Heel that exposes the system as if no security was implemented at all.

Security in the Future

All security in information systems is dependent on cryptography. As such, security mechanisms can be circumvented by decrypting information used to support these mechanisms. Given enough time, any cipher can be broken. However, this could require thousands of years. Security derives its strength, therefore, not from the obscurity of its algorithms, but from the unreasonably large investment in computational time that is required to break any given cipher.

Faster computers, and in particular distributed (parallel) computing, significantly expand the speed at which security systems can be compromised. Ciphers that might have taken a team of mathematicians decades to break before the advent of modern computers, could today be broken by software in mere seconds. The 56-bit RC5 encryption that would require a single desktop computer to dedicate thousands of years to the task (and could thus have once been considered sufficiently secure) was, in 1997 broken after 250 days of a massively parallel computational effort by tens of thousands of ordinary desktop computers¹.

From this it is clear that no specific algorithm can become the cornerstone of a security system, unless its effective lifetime were meant to be limited from the start. An essential design principle is, therefore, that the security interface be separated from the implementation of the security algorithms, allowing the implementation to be upgraded to keep pace with advances in anti-crypto systems and ensuring that system security can be maintained at a sufficient level to satisfy the requirements of authentication, access control, integrity assurance, and confidentiality in the future.

Security in the IMS

The IMS requires security for a variety of reasons. First, achievement (performance) records as well as demographic student information must be safe from unauthorized access. IMS security must also safeguard from possible falsification of such performance records and prevent forged records of unearned accomplishments from being added to a student's profile. Second, the IMS must ensure that whoever uses its resources is actually authorized to do so, not merely to restrict access to unlicensed material but also to provide a framework to effect authorized billing for the use of such resources. And third, information exchanged between software components within the IMS, between different IMS's and users must be secured to ensure such that the data cannot be misappropriated and the privacy of user violated.

This section refers to some specific technologies in order to clarify security concepts. The IMS does not, however, dictate the use of any particular technology to implement any part of its security features. Instead, the IMS specification includes high-level interfaces to security services.

The separation of security features into interfaces and implementation enhances the portability and inter-operability of IMS components, but also ensures that new security technologies can be integrated into the IMS to keep pace with cryptographic advances.

Authentication and Confidentiality

Computers on the Internet today frequently employ a concept referred to as Public Key Cryptography in order to keep information from being viewed by others. This same technologyis also used to establish trust in the identity of two parties that exchange information over an insecure line (one whose integrity cannot be known and which cannot be guaranteed to be free of the possibility of having the information intercepted)

Public keys play an important role in computing today because they permit two parties to trust each other's identity and then engage in private communications without either party ever having met the other. Traditionally, an exchange of secret keys was the only means of ensuring secure communications. Public key cryptography eliminates this need.

Communications between two parties are encrypted and decrypted with a private key and the other party's public key. Each party has ready access to the other's public key, but neither is ever privy to the other's private key.

As the computational overhead of public keys is significant, secure communications between two parties usually involve the exchange (via public keys) of an alternate encryption method based on secret keys. The computationally less expensive secret keys enable significantly faster exchange of confidential information.

It is important to recognize and understand that a public key is by no means trusted in and of itself. A public key establishes no identity, unless at least one other trusted entity verifies that identity. Verifying identities is usually the role of so-called Certificate Authorities, whose authority is trusted by virtue of their established presence and widely accepted trust, and whose signature on someone's public key guarantees the identity of the owner of that key.

Once both sides have determined that the public keys that were exchanged indeed validate the other's identity, a cryptographically secure (confidential) and trusted (authenticated) communication has been established.

Another aspect where public keys play an important role is in authenticating data: Digital signatures provide a means of signing (i.e. authenticating) arbitrary information, and when based on public keys allow unrelated parties to verify the authenticity of the signature. This is also closely related to ensuring the integrity of information: any change is easily detected by checking data against its digital signature.

Access Control

Access Control cannot be successful without proper authentication such as was established according to the principles presented in the previous section.

Access Control is principally concerned with controlling access to information. In particular, the confidentiality and integrity (coherency) of student records must be ensured; learning materials may only be available to students who have been in some other way given access to the materials, such as by paying a fee.

The focus of the IMS to serve not merely as a single-learner, but also as a collaborative learning environment comprised of groups (teams) and collections of groups (classes), raises additional issues of permitting access to learning materials based on a student's associations, rather than simply the student's individual identity.

A commonly employed metaphor for managing groups of people according to a classification or a relationship to a group or organization is reflected in the Role Based Access Control (RBAC) model², that was developed by the National Institute for Standards and Technology (NIST). Administrators already think of individuals in terms of their job position or their role within an organization. This view is easily translated to the IMS by viewing an individual as a "member of the Biology 240 class" or a "user of Freddy's Frog Fragmentation Kit."

Considering that RBAC is a natural representation of existing administrative policies and procedures, the adoption of RBAC in the IMS lowers the cost of administering an IMS system's access control policy and reduces the chance of errors when compared to other access control mechanisms, in particular when such mechanisms directly associate users with specific permissions.

The RBAC model also supports non-trivial access control policies without compromising efficient implementation, which is an important consideration when large-scale IMS environments need security policies enforced through such a role based access control model.

RBAC is not the only means by which IMS applications and objects are protected from unauthorized access, of course. An object could make authenticated requests to other IMS objects to obtain additional authorization beyond what the RBAC model offers, and thus extend these basic services in ways that are dictated by the unique needs of a particular object.

Implementation Issues

With IMS security services separated from the actual implementation through the use of an interface specification, the actual implementation of of these security services may range from minimal to complex, as dictated by the needs of a particular installation.

Public Key Certificates

Authentication and confidentiality services may be provided through the use of security systems that support public key algorithms. Such systems include the Secure Socket Layers (SSL) protocol, ssh (secure shell), CORBA, COM, and Kerberos.

Although public key certificates are in widespread use, an organization is likely to require investment in additional infrastructure to make consistent use of such certificates across multiple systems. While the technology to support this infrastructure is available, there are serious organizational and legal policy questions that must be decided by an organization before using the technology.

A user's public key certificate may be provided by the user directly, or by a known public key server, provided that the user has registered his/her public key with such a server. The public key supplied by a third party in this manner may require an additional verification step by which the public key server's identity is authenticated. Towards this end, the public key server would need to present an authenticating certificate that has been signed by a known and trusted certificate authority, perhaps VeriSign or others.

RBAC Model

In addition to its own services, the Role Based Access Control (RBAC) model is flexible enough to allow the actual implementation to choose from or implement custom authorization systems that match the installation's need, size and other aspects of its environment³. In this way, RBAC not only adapts itself to existing policy models, but may also be extended as the need arises.

Securable Objects

In order for IMS objects to be securable, i.e. able to take advantage of authentication, access control, integrity services, and confidentiality assurance, these objects must implement a so-called security interface. Through this interface arbitrary objects can be queried for certain security-related properties, thus making these objects securable.

Methods (functions) that implement the security interface are:

authorizedRoles
Obtain information on the authorized roles that may access the object.

digitalCertificate
Obtain the object's digital certificate.

InvokeSecure
Invoke the object's purpose/function using security credentials.

Scenario Walk-through

At hand of the following scenario we hope to demonstrate, in a somewhat simplified manner, how the services described above, function in an Instructional Management System:

Pat dials up and establishes a connection with an Instructional Management System (IMS). Pat's computer and the IMS present to each other their respective public keys. The public key of the IMS has been signed by a certificate authority that is recognized and trusted by Pat's browser software. Likewise, Pat's public key was signed by an entity that the IMS recognizes and trusts (perhaps even by the IMS itself.)

Pat and the IMS can now both be certain of the identity of the other (meaning that neither will accidentally reveal to the other information, such as a password, that could be misused by an impostor), and in addition, both can use their respective public keys to encrypt any and all data that they exchange. Their communication is, therefore, confidential, meaning that nobody else can intercept this information and gain access to it.

Pat now decides to resume previous work with Freddy's Frog Fragmentation Kit (F3K). Calling up the F3K software causes the F3K to request from the IMS authorization to offer its services to Pat. Through Pat's session information, the IMS knows that Pat is a member of "Biology 105". Members of this group are indeed allowed to use the F3K, according to the access control services used by the IMS, so the F3K receives the "OK" that Pat may go ahead.

After Pat finally completes the work, the F3K object creates a performance record that becomes part of Pat's permanent profile. This performance record is digitally signed by the F3K software, so that its authenticity can be verified at any time in the future. Anyone recognizing the identity of the signing entity (the F3K software, in this case, or the owner of the key that the F3K software uses) will recognize that Pat has indeed obtained the performance record through legitimate use of the F3K software.

¹	See distributed.net
²	David Ferraiolo and Richard Kuhn. Role-Based Access Controls. In Proceedings of the 15th National Computer Security Conference, Vol II, pp 554-563, 1992. (see also National Institute of Standards & Technology)
³	John Barkley. Implementing Role Based Access Control using Object Technology. National Institute of Standards and Technology. 1995.