Aloaha Smartlogin contains a Credential Provider for Windows Vista/7/8/2008/2012 and a Gina for older windows. It supports many different ways to logon a user to the windows session.

Active Directory is supported but NOT required!

The most popular way of using Aloaha Smartlogin without Active directory is with “any Smartcard natively supported by Windows or 3rd party middleware” as explained in http://blog.aloaha.com/2012/08/13/what-are-softtoken-in-aloaha-smartlogin/

Now we introduced new registry settings to allow the user to maintain one central, server based CredentialStore.

If you point the Registry Key: ”HKLM\Software\<Wow6432Node\>Aloaha\CSP\ForcedCredentialStore” to a share in your network Aloaha will copy automatically all files from that network store to the local machines credential store (<installdir>\CredentialStore) whenever the user logs on.

Many important settings are saved in the local file UserPass.ini. If you point ”HKLM\Software\<Wow6432Node\>Aloaha\CSP\MasterUserPassIni” to a file this file will be automatically copied to the file defined in ”HKLM\Software\<Wow6432Node\>Aloaha\CSP\UserPassIni” (Usually <installdir>\UserPass.ini)

Please dot not hesitate to contact us at info@aloaha.com in case you need further and personal assistance.

The latest release of the Aloaha Smartcard Middleware Aloaha Smartcard Connector (http://www.aloaha.com/download/cardconnector.zip) now also supports the popular Muscle Applet.

Included in the Middleware is a Crypto Service Provider, PKCS #11 Module, Harddisk Encryption and a Password Safe.

As an add-on the user can use Aloahas Smartlogin for Smartcard based Windows Logon with or without Active Directory. (http://www.aloaha.com/download/smartlogin.zip)

Some weeks ago we explained how to disable unwanted Credential Providers completly.

http://blog.aloaha.com/2012/08/20/how-to-hide-credential-providers-from-the-windows-logon-user-interface-using-windows-group-policy/

Aloaha Credential Provider Filter

In some cases Credential Providers should be hidden from the Logon User Interface BUT still usable from within the session. For example somone might not want to see the Username/Password Tile during logon but obviously still requires it when mounting a network drive or connecting via RDP to another machine. In those case you cannot hide/disable the providers via windows group policy but a Credential Provider Filter is required.

Aloaha Smartlogin comes with an integrated Credential Provider Filter to be able to hide Tiles from the Windows Logon Interface WITHOUT removing its functionality inside the session.

To activate the Aloaha Credential Provider Filter you need to open the file UserPass.ini in the installation folder. In the section CredentialProviders you can configure different filter for different provider. To enable a filter please set it to 1. Below the section to disable ALL non Aloaha Provider:

[CredentialProviders]
25CBB996-92ED-457e-B28C-4774084BD562=1
3dd6bec0-8193-4ffe-ae25-e08e39ea4063=1
503739d0-4c5e-4cfd-b3ba-d881334f0df2=1
6f45dc1e-5384-457a-bc13-2cd81b0d28ed=1
8bf9a910-a8ff-457f-999f-a5ca10b4a885=1
94596c7e-3744-41ce-893e-bbf09122f76a=1
AC3AC249-E820-4343-A65B-377AC634DC09=1
e74e57b0-6c6d-44d5-9cda-fb2df5ed7435=1
F8A0B131-5F68-486c-8040-7E8FC3C85BB6=1

You can digitally sign documents by using Microsoft Excel 2010, Microsoft PowerPoint 2010, and Microsoft Word 2010. You can also add a signature line or signature stamp by using Excel 2010, Microsoft InfoPath 2010, and Word 2010. Microsoft Office 2010 includes support for XAdES (XML Advanced Electronic Signatures), which is a set of extensions to the XML-DSig standard. This was first supported in the 2007 Microsoft Office system.

Also, if XAdES is used for the digital signature in Office 2010, the digital signature would not be compatible with the 2007 Office system unless you configure the Group Policy setting, Do not include XAdES reference object in the manifest, and set it to Disabled. For more information about the digital signature Group Policy settings, see Configure digital signatures later in this article.

If you need digital signatures created in Office 2010 to be compatible with Office 2003 and earlier versions, you can configure the Group Policy setting, Legacy format signatures, and set it to Enabled. This Group Policy setting is located under User Configuration\Administrative Templates\(ADM\ADMX)\Microsoft Office 2010\Signing. After this setting is set to Enabled, the Office 2010 applications use the Office 2003 binary format to apply digital signatures to Office 97–2003 binary documents created in Office 2010.

Time stamp digital signatures

The ability with Office 2010 to add a time stamp to a digital signature allows for helping to extend the lifespan of a digital signature. For example, if a revoked certificate has previously been used for the creation of the digital signature, which contains a time stamp from a trusted time stamp server, the digital signature could still be considered valid if the time stamp occurred before the revocation of the certificate. To use the time stamp functionality with digital signatures, you must complete the following:

1. Set up a time stamp server that is compliant with RFC 3161 such as the Aloaha TSA
2. Use the Group Policy setting, Specify server name, to enter the location of the time stamp server on the network.
3. You can also configure additional time stamp parameters by configuring one or more of the following Group Policy settings:
4. Configure time stamping hashing algorithm
5. Set timestamp server timeout

Please have a look at http://blogs.technet.com/b/office2010/archive/2009/12/08/digital-signitures-in-office-2010.aspx?PageIndex=3 

If you get the error: “timestamp server is not available” you will have invalid entries in your system policy. Just search the registry for tsa.aspx to locate them! Often a simple machine restart is also enough! GPUPDATE /force seems NOT to be enough for the cleanup!

If you do not configure and enable Configure time stamping hashing algorithm, the default value of SHA1 will be used. If you do not configure and enable Set timestamp server timeout, the default time that Office 2010 will wait for the time stamp server to respond to a request is 5 seconds.

Configure digital signatures

In addition to the Group Policy settings for configuring time stamp related–settings, there are other Group Policy settings to configure how digital signatures are configured and controlled in an organization.

Der manipulationssichere Zeitnachweis für Ihre Anwendungen, Dokumente und Ablaeufe.

Bei vielen Geschäftsprozessen ist es wichtig, den genauen Zeitpunkt bestimmen zu können, zu dem die entsprechende Transaktionen stattgefunden hat. Der TimeStamp Server/Time Stamping Authority von Aloaha hält manipulationssicher fest, wann eine Transaktion stattgefunden hat oder ein Dokument in einer speziellen Form existiert hat.

Je umfassender die wirtschaftlichen oder rechtlichen Auswirkungen sind, z.B. bei der elektronischen Übermittlung von Ausschreibungsunterlagen, desto wichtiger ist ein verlässlicher Zeitstempel. Aloahas® TimestampServer ist ein Windows Dienst und bietet ein Höchstmaß an Authentizität und Manipulationssicherheit bei der Generierung von Zeitstempeln.

Produktdetails

• RFC 3161 Zeitstempel Protokoll
• Microsoft Authenticode Protokoll
• Zeitstempel Protokoll über HTTP und Web Services
• „Plug & Play“ Benutzung in vielen kommerziellen Anwendungen, z.B. Adobe Acrobat®, Microsoft Office, SAP, etc
• Synchronisierung der Timestamp Server Uhr mit einem externen Zeitserver
• Einfache Integration in bestehende Netzwerkstrukture
• Zeitstempel Zertifikate koennen sich in einem PFX, einem HSM Modul oder dem Windows Zertifikatsspeicher befinden

Kryptographische Algorithmen
Entsprechend dem ETSI-Standard TS101861 unterstützt der  TimestampServer die folgenden Algorithmen:

• RSA
• Hash-Algorithmen SHA-1, SHA-2 Familie, RIPEMD-160, MD5

Mehr Details auf der Produktseite: http://www.aloaha.de/wi-software/aloaha-timestamp-server.php

Eine Evaluation Version kann von http://www.aloaha.com/download/tsa.zip geladen werden. Ihren Evaluation Key erhalten Sie von info@aloaha.com

Run your own Timestamping Server

There are two ways of operating the Aloaha timestamping Authority. You can either integrate our COM Interface into your IIS so that your IIS starts serving the timestamp token

or

you just install our ready to go package http://www.aloaha.com/download/tsa.zip. Once installed it will right away serving on Port 8081. For example http://<your host>:8081/tsa.aspx. Please note that the stand alone package does NOT require any local web server running since it comes with its own tiny web server.

It is always suggested to start with Timestamping Application from http://www.aloaha.com/download/tsa.zip. Should you decide to to the manual and more time consuming way please follow the steps below.

To integrate your own timestamping Authority in IIS you need:

• Aloaha Cardconnector (http://www.aloaha.com/download/cardconnector.zip)
• Web Server on Windows Machine (ideally with ASP or ASP.NET support)
• Enabled POST Verb support in Web Server (in modern IIS deaktivated per default!)

After you installed and licensed (please note that the TSA needs a special license) the Aloaha Cardconnector you need to configure your web server. Even though PHP, etc will work we can only give support for ASP and ASP.NET

To configure your webserver please make sure that:

1. It supports the POST Verb (as mentioned above modern IIS have this feature deactivated per default)
2. You configure a Web Application and enable 32 Bit support
3. You configure the above Web Application to run as User X. User X must have access to the Time Stamping Certificate in your certificate store.
4. set HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Aloaha\TSA\UseCertfromStore to 1 so that Aloaha uses the best TSA Certificate in the current User Store of User X
5. Logon as User X in case you are going to use a software certificate. Import that certificate into the Current User Store of User X.
6. Logon as User X in case you are going to use a HSM Module. Configure the HSM that it maps the certificate into the Current User Store of User X

Now configure your ASP or ASP.NET Application.

ASP

Use a script similar to: http://card.aloaha.com/AloahaTSA/tsa.txt

ASP.NET

Use Code similar to:

http://card.aloaha.com/tsa/tsa.aspx.txt and http://card.aloaha.com/tsa/tsa.aspx.vb.txt

Please note that the core module is 32 Bit. It is essential that your enable 32 Bit support for your ASP/ASP.NET application. Furthermore the Application User requires access to the Current User Store holding the certificate or certificate reference of the Time Stamping Certificate!

It is also possible to use directly PFX files. In case you have questions or in case you need assistance to configure your TSA please do not hesitate to contact info@aloaha.com

In case you require a ready configured package without the requirement to write scripts, configure web server, etc. please install http://www.aloaha.com/download/tsa.zip. I license can be requested at info@aloaha.com

Our TSA Web Service is online at http://card.aloaha.com:8081/default.asmx

The normal POST URL is: http://card.aloaha.com:8081/tsa.aspx

The timestamp token archive can be found on: http://card.aloaha.com:8081/archive

The new Aloaha Smartlogin has been released today. It can be downloaded from http://www.aloaha.com/download/smartlogin.zip

Evaluation Keys can be requested from info@aloaha.com

Aloaha Smart Login

Our new version supports a broad range of Logon Token:

• Plain USB Memory Stick. Username/Password is saved encrypted on any plain USB Memory Token. This feature is currently freeware and does not require any domain.
  http://blog.aloaha.com/2012/08/12/use-plain-usb-memory-stick-as-windows-logon-token/
  video: http://blog.aloaha.com/2012/07/25/windows-logon-with-plain-usb-memory-stick/ 
• I2C Memory Card. Username and Password are written encrypted to the Memory Card. This mode does NOT require any domain or middleware installed and furthermore i2c cards are very cheap!
• PKCS#11 Token. The Username and Password can be saved in a protected field on your PIN protected PKCS #11 Smartcard or Token. The machine is not required to be member of any domain!
  http://blog.aloaha.com/2012/08/12/how-do-i-save-my-logon-credentials-to-a-pkcs11-token/
  video: http://blog.aloaha.com/2012/07/26/windows-logon-via-credentials-saved-encrypted-on-pkcs-11-token/
• Any Smartcard natively supported by Windows or 3rd party middleware. We call this also Encrytion Token since Username and Password will be encrypted with the certificate on the card but saved locally (or on a share/URL) as encypted softtoken. To logon the user needs the PIN, the smartcard and the softtoken has to be reachable. This methods works without any domain controller!
  http://blog.aloaha.com/2012/08/13/what-are-softtoken-in-aloaha-smartlogin/ 
  video: http://blog.aloaha.com/2012/07/28/windows-logon-via-any-smartcard/ 
• PKI/Kerberos Logon with Windows or 3rd Party supported smartcard as above but in this new mode NO Username or Password is being saved anywhere. The logon is a pure Kerberos Logon. That implies also that a Domain Controller and a Domain Certificate is required!
  video: http://blog.aloaha.com/2012/07/29/windows-logon-via-any-smartcard-and-kerberos/

Requirements

1. Windows XP 32 bit
2. Windows Vista or higher (32 and 64 bit)
3. “Smart Card” Service running (SCardSvr)
4. .NET 3.5 or higher installed
5. Logon Token. For example USB Memory Key, Smartcard, Memorycard, Mobile.

Special Features:

Licensing

• The use of Plain USB Stick token is freeware
• For licensed user of the Aloaha Middleware (Aloaha Cardconnector) Smartlogin is freeware
• Licenses for Smartlogin can be purchased on http://www.aloaha.com/shop-en/aloaha-smart-login.php

Softtokens are your credentials encrypted with a certificate hosted on your smart card. For the logon then the Smartcard, the Smartcard PIN and the Softtoken is required! So actually it is a 3-factor authentication and it does not require any domain controller!

To create a Softtoken insert first your smartcard in the cardreader. Then make sure that all card certificates are registered in your system.

Now you can start the tool Credential Manager (SetCredentials.exe) from your start menu.

Aloaha Credential Manager

The usage is quite easy. Just mark the certificate you want to use to create your encrypted softtoken. Then enter Username, Domain and Password and press Save. To validate the saved and encrypted credentials just press directly validate.

With the filter on the right you can filter our some certificates from a list of many certificates.

Aloaha Smartlogin supports ANY Smartcard loaded with a certificate. In this video it is shown how to use Aloaha together with a SafeNET Token.

The Smartcard can be also a secure uSD or the secure SIM developed by Aloaha.

You can download the software from http://www.aloaha.com/download/smartlogin.zip

Aloaha Smartlogin exists in two editions. One edition includes the Aloaha Smartcard Connector (CSP) supporting ca. 45 different cards. Those cards can be connected via PC/SC (CCID) or CTAPI (for example eHealth Terminals.

Some customers require a more generic Windows Logon Solution. For example because their card is not one of the 45 supported cards OR they are forced to use their own smartcard middleware.

The second edition supports any smartcard via its middleware (cryptoAPI/CSP) or PKCS #11 module. When using the card via middleware/crypto API the user credentials will be encrypted with the smartcard certificates and stored as a softtoken on the local harddrive or network share. Basically this solution is a 3-factor logon solution since it is require to know the PIN of the Card, the possession of the smartcard AND the existance of the Softtoken.

In case user do not want to use the softtoken based 3-factor solution they can opt to use the PKCS #11 Interface of their middleware. When using the PKCS #11 Library Aloaha will save the user credentials encrypted in a private object ON the card itself!

To store the credentials on the card the user needs to call “PKCS #11 Credentials” from the start menu or PKCS11Credentials.exe from the installation folder (<program files>\wrocklage)

Aloaha Smartlogin PKCS #11 Interface

As a first step the PKCS #11 Library to be used has to be defined! Once that library has been choosen all available token will be listed.

If there is more than one token the user has to select the token to be used in order to save user credentials to the token.

The token removal behavior will be read from the system policy OR from the file Userpass.ini. For details please contact support at info@aloaha.com

To install this edition of Aloaha please download http://www.aloaha.com/download/smartlogin.zip

Please note that a license key is ALWAYS required! Evaluation keys can be requested from info@aloaha.com