Jaa

Custom authentication mechanisms

  • Artikkeli

**Updated 3/26/09 with preface

[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]

In a lot of usage scenarios the standard Windows authentication mechanism “Windows Logon” is not the appropriate way to handle user authentication. This may be due to the lack of input devices such as keyboard, or the fact that the device is running a custom shell, which never is logged off.

Authentication levels

Windows systems normally have a single, built-in authentication boundary at OS level, where the user either authenticates against the local user database or an Active Directory domain controller. Once this has been successful, the user gains access to a systems resources based on his user privileges. Applications, especially when used in an enterprise environment, commonly introduce a second layer of authentication, when a user needs to provide additional credentials to the application. Execution environments such as the .Net Framework use even more sophisticated mechanisms called Code Access Security (CAS) to determine if the code should be run or not. This is a mixture between a permission based security model (user context) and the ability to determine the origin of the code using certificates.
For embedded developers it is good to know that all of these mechanisms can be customized to satisfy the needs of an embedded device

Replacing Windows Logon

In Windows, the Graphical Identification and Authentication DLL called Gina.dll implements the logon process. This part of functionality can be completely replaced by a custom implementation. The corresponding documentation on how to do this can be found in the MSDN library as well as in this very interesting whitepaper “The essentials of replacing MSGina.dll”. Please be aware that this task is not done on a Sunday afternoon and requires a thorough understanding of the Windows security architecture! In addition, it is important to know that you can only do a complete exchange of the logon functionality and you would also need to support the custom implementation. To reduce this complexity, there are commercial as well as open source implementations like FrontMotion and pGina, which introduce plug-in models to simplify the development of your custom Gina functionality.

Quite often, especially looking at innovative authentication mechanisms using biometric or RFID technologies, a customized Gina dll is provided by the manufacturers. There are systems that use Iris recognition even via webcam, Smart Cards or active RFID tags to log on to a Windows system.

Application level authentication

It is also common that embedded systems running a custom shell do not use the Windows logon mechanism, but a custom approach at application level. This can be, for example, queries with user-provided credentials against a SQL database or an LDAP directory. This approach provides a lot of flexibility, while at the same time enhances security. Application level authentication always means that the system , either using automatic logon or the Windows Embedded Standard MinLogon configuration, needs to be booted into a Windows desktop before authentication takes place, which gives some leeway for intrusion attempts.
It also requires any custom shell to be very robust. It should be able to lock down the system as much as possible.

Code access security (CAS)

CAS is a very secure way to execute code. It relies on certificates to guarantee the identity of the code’s origin. There is a great article by Mike Owen explaining its basic functionality. CAS security enables software developers to run their applications (such as a custom shell) in the context of a user account with the least possible rights, while at the same time allowing portions of code to obtain a privilege elevation to do security sensitive tasks.

What to choose?

If implemented correctly, a custom Gina Dll, in my eyes, still provides the highest level of security, but requires some implementation effort or the use of 3rd party tools or frameworks. Application level authentication is quite straight forward to realize and provides a lot of flexibility, but leaves some security challenges to be mastered. To use CAS, a user must already be logged in, because CAS is not an authentication mechanism per se. However, it is a good way to combine a low rights user context with secure application execution. In an embedded scenario this could be leveraged to use a low privileged account to log onto the system automatically and then leverage portions of elevated code to do interesting things in a custom shell, without compromising overall system security.

Best practices

Authentication mechanisms for embedded devices should be easy to use and therefore should have a low profile from the user’s perspective. It really can be considered a best practice to provide consistent single sign-on from OS to application level - recent Microsoft technologies like the new Terminal Services in Server 2008 demonstrate this impressively in thin client scenarios.

- Alexander

Alexander Wechsler

Wechsler Consulting

www.wechsler-consulting.de

Technorati Tags: XPe,Embedded

Comments