Around the world with Smart-Cards

Security is a basic virtue of IT--especially if in the case of illegal access to the systems, human life or costly materials are endangered. Accordingly sophisticated is the security plan in the Space-Control center of the German Aerospace Center in Oberpfaffenhofen. Here the Columbus-Module of International Space Station ISS is controlled round the clock.

As in many other enterprises with high security requirements, the concept of DLR is based on separate networks of different protection levels that are physically not connected to each other: in the so-called Ops network the actual navigation of the research module in Earth's orbit takes place. Among other services, it also controls the life-support-systems. Here, strictest security measures, as used by banks, are applied so that no unauthorized person can send commands to ISS. Parallel to this, there is the network "Ops Support". In this particular segment different help software is used by the flight controller, for instance, a tool for the most precise daily scheduling of the ISS crew. The security demands here are comparable with the standards in sensitive areas of other industries. An error in the system or extern fraudulent manipulation of the IT infrastructure could cause serious disruption of the space mission - apart from high costs. "Office Network" requires lower security. Only in this section of the infrastructure can the internet be accessed. Office programs and emails dominate this section. DLR outsourced most parts of the IT system operations to external service providers.

The company INSYEN AG is responsible for the Ops support network on the premises of DLR. All the specifications for IT structuring are set up by European Space Agency (ESA) which appoints DLR to control the Columbus Module. Thus, it is a requirement of the ESA, for instance, that user authentication takes place exclusively over a central Lightweight Directory Access Protocol (LDAP) server. Moreover, in a highly critical Ops network it is additionally required that access takes place with the Smart-Card – an authentication method that was extended also for the Ops support network. The basic problem is explained by Mr. Harold Stössner, administrator of Ops support network: "The Ops support network grew out of a Windows domain. To link or to connect LDAP as the leading system here together with Windows would mean an enormous effort."

The integration of the Smart-Cards would also be very complex. "That's why we have looked for a solution that can connect all three worlds together: the active directory of the Windows domain, the central LDAP services and the authentication with Smart-Cards", adds Jürgen Fein (responsible for the processes in the DLR control center) to explain the initial position.

A basic technical problem hereby is that the active directory normally wants to be the master within the domain. However, at DLR according to ESA specifications, LDAP has to be the master and the Windows domain controller in the Ops support sub-system has to be second in line.

"To change the existing active directory was not a reasonable option.", points Mr. Fein. "Running in the Windows domain are important tools of NASA that were designed for Windows and that assume a Windows environment."

The choice and evaluation of an adequate solution as a bridge between the different system worlds could be approached very carefully, according to Fein, as the requirements were given in advance.

"There wasn't much choice," recalls Stössner, "We only found one product that fulfills all of our requirements." Accordingly, the decision fell to the solution "Sign-on Gate" of the Viennese company Comtarsia Services GmbH.

First of all a back-up control room was set up to evaluate this solution. The DLR Control Center is able to test new IT solutions during the training and advanced education of flight controllers in practical simulations of normal activity. In this way it was easily detected where the chosen solution had to be adapted to the individual need.

This includes, for instance, the use of more PC's per work area: Through strict division of the three networks, the flight controllers at DLR operate with three calculators, each of them being separately and fixedly assigned to one of the three networks. Normally, at the authentication with Smart-Card, a user is logged out or the PC is locked when the card is taken out of the reading device. In the control center this was not permitted to happen—the users register with one card at all three computers. This card also serves as an entry control to the flight control room and to the buildings. "Within our security context that includes rigid multilevel access controls and physically separated networks, we can tolerate that the user stays registered in the Ops support network, even if the Smart-Card is removed.", according to Mr. Fein. "In the high-security Ops network that runs the control of the Columbus-Module, this would not be permitted." Comtarsia implemented the required functions.

Another hurdle was the highly heterogeneous environment. Smart-Cards are being used in two subsystems: Ops and Ops support. Still, in both systems there are two different solutions being used for authentication. This has both historical and technical reasons: Smart-Cards had been used already for awhile in a high-security Ops network that is based on a Linux server and clients. The software used there for user authentication would have been, according to Fein and Stössner, very difficult to be transferred into a Windows domain. In addition, the already introduced Smart-Card system of the Linux infrastructure was not compatible with the Windows world. Thus, it was technically not prudent to implement this in extending it to other subsystems.

This obstacle was solved using Comtarsia solution as an authentication interface between the two subsystem worlds. The introduction of the solution took place, without problems, after implementing all necessary changes. The specific use started in June 2008. Log on to the PC in the Ops Support System is carried out in several steps: first with the help of Smart-Card data and the users PIN, a client's certificate is issued and user authentication is established by the LDAP server. If the registration at LDAP is successful, a sign-on request at the "Sign-on Gate" service from Comtarsia is sent, that is installed directly with the Windows domain controller. This process starts the automatic user administration in the active directory: the user is registered directly at the Windows domain; if the user isn't found there, LDAP creates a new account with the new attributes. With each log on, Sign-on Gate updates the user information, for instance information on the group membership, in order to synchronize the information deposited in the leading LDAP with the one of the active directory. In order to avoid bypass of log on to the Windows work station with Smart-Card and PIN number, random created passwords will appear in the background with the Windows log on.

Fein and Stössner are satisfied with these achievements so far. "The whole project was successfully brought to its end without any considerable trouble", says Fein. "All individually desired changes were quickly implemented, we would implement the project anytime the same way." The return on investment (ROI) was not an issue. "As far as we know, there was no alternative to meeting the specifications of ESA with the existing infrastructure.", according to Fein. Additional to that, DLR sees it as positive that the needed function extensions from Comtarsia will be implemented in future versions of the Sign-on solution. This way, implementation of the solution remains release-capable. Updates or new versions can be downloaded without any complicated adjustments.