What is a self-signed certificate?

In cryptography and computer security, a self-signed certificate is an identity certificate that is signed by the same entity whose identity it certifies. This term has nothing to do with the identity of the person or organization that actually performed the signing procedure. In technical terms a self-signed certificate is one signed with its own private key.

Free self signed certificates can enable the same level of encryption as a $1500 certificate signed by a trusted authority, but there is a major drawback: the certificate cannot be revoked like a trusted certificate can.

When shall I use a self-signed certificate?

A certificate serves two essential purposes: distributing the public key and verifying the identity. The identity can only properly verified when it is signed by a trusted third party because any attacker can create a self signed certificate and launch a man-in-the-middle attack. If a user just accepts a self signed certificate, an attacker could eavesdrop on all the traffic or try to set up an imitation server to phish additional information out of the user. Because of this, you will almost never want to use a self signed certificate on a server that requires anonymous visitors to connect to your site..However, self signed certificates have their place:

• In the Intranet. When clients only have to go through a local Intranet to get to the server, there is virtually no chance of a man-in-the-middle attack.
• On a development server. There is no need to spend extra cash buying a trusted certificate when you are just developing or testing an application.
• Personal sites with few visitors. If you have a small personal site that transfers non-critical information, there is very little incentive for someone to attack the connections.
• Encrypting Documents such as PDF Documents (Aloaha PDF Crypter) to protect Documents against theft.
• Use as an encryption Certificate for Aloaha secureZIP

Just keep in mind that visitors will see a warning in their browsers (like the one below) when connecting to an server that uses a self signed certificate until it is permanently stored in their certificate store.

In Windows there are several ways to create your own self signed certificates. Some methods involve installing 3rd party tools or using command line tools. With the Aloaha CertificateCreator your own digital certificate is just one simple click away.

The Aloaha Certificate Generator will create certificates you can use for testing secure applications and web sites. These certificates should not be used in a production environment because they are not signed by a trusted certificate authority.

Aloaha CertificateCreator

Just download the tool from https://dl.dropboxusercontent.com/u/20338532/neverdelete/AloahaCertificateCreator/AloahaCertificateCreator.zip or https://dl.dropboxusercontent.com/u/20338532/neverdelete/AloahaCertificateCreator/AloahaCertificateCreator.exe

and start it directly. It is a portable tool so it does NOT need to be installed nor does it leave any traces behind!

Now you just fill in your name, choose the right store and define if the private key should be exportable or not. Once you click Generate and the certificate has been generated a small confirmation window will pop up.

In case you need to generate a self-signed SSL Certificate you need to fill in your domain name into the name field!

When you choose the store please note the “Current User Store” is ONLY available for the currently logged on user. If you want that services, other users, etc. have access please use the “Local Machine Store”.

Per default generated certificates are exportable. That means you can easily export the certificate and private key into a .PFX file to take to any other machine to import it there. The PFX can also be imported to a smart card or any PKCS #11 token.

If you need to make sure that the private key CANNOT leave the machine then you need to DISABLE exportable. This is useful if you want to certificate encrypt a file or PDF (please see the PDF Crypter) in such a way that it CANNOT be opened on any other machine.

With the commercial version of this tool you have the chance to use it with command line parameter or even as a .NET Component for your own projects. Please contact info@aloaha.com for further information.

With the Aloaha Password Filter (Details: http://blog.aloaha.com/2013/04/28/aloaha-passwort-filter/) it is possible to synchronize the certificate encrypted softtoken on any password change the user does.

Since the tracked password are encrypted with the public key of the users certificate this mechanism works ONLY if already a softtoken exists.

Softtokens can be created manually with the tool PasswdHK from the Aloaha Installation folder.

Sometimes it is required that tokens are created automatically. For example for new users which are forced to change their password at the first logon. For those users you need to create a registry entry pointing to their certificate (.cer file/public part)

The settings are done in HKEY_LOCAL_MACHINE\SOFTWARE\<Wow6432Node>\Aloaha\CSP\CertificateMapping on the machine running the password filter.

Please note that for domain users the filter needs to run on the domain controller and for local user it needs to run on the local machine!

For example for a local user:

[HKEY_LOCAL_MACHINE\SOFTWARE\<Wow6432Node>\Aloaha\CSP\CertificateMapping]
“stefan”=”c:\\certificates\\stefan_2013_for344.cer”

For example for a domain user in domain wrocklage:

[HKEY_LOCAL_MACHINE\SOFTWARE\<Wow6432Node>\Aloaha\CSP\CertificateMapping\wrocklage]
“stefan”=”c:\\certificates\\stefan_2013_for344.cer”

Keeping the certificate encrypted tokens in sync makes a lot of sense with the central store explained on: http://blog.aloaha.com/2013/04/26/aloaha-smartlogin-with-central-credential-store/

The Aloaha Passwort Filter is a Windows Password Filter to synchronize password changes with the Smartcard encrypted Softtoken of Aloaha Smartlogin.

When a password change request is made, the Local Security Authority (LSA) calls the password filter registered on the system. The Aloaha Password Filter is called on the machine the password change has been done. If the password change has been done for an Active Directory User the filter is called on the Domain Controller and if the User is a local user the filter is called on the local machine.

To install an activate the filter please start PasswdHK from your Aloaha installation folder. It is VERY important to call it with admin rights. Ideally you call it with -> right mouse click -> “Run as Administrator”. Once the tool is running please choose the tab “Activate Password Hook” and click on “Enable”. After clicking “Enable” or “Disable” a reboot is required!

The other tab “Set initial Password” has the function to create a certificate encrypted softtoken. Those certificate encrypted softtoken are used by Aloaha Smartlogin to allow the User a Smartcard Logon INDEPENDENTLY of Active Directory Membership and Certificate origin!

Passwords intercepted by the Aloaha Password Filter ARE ALWAYS encrypted with the public key of the certificate defined in the Softtoken. Therefore password are ONLY synchronized when a softtoken exists!

Keeping the certificate encrypted tokens in sync makes a lot of sense with the central store explained on: http://blog.aloaha.com/2013/04/26/aloaha-smartlogin-with-central-credential-store/

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)

With faster machines and even faster hard drives (SSD) holding large rainbow tables the average cracking time on a dual processor machine came down to just 15 minutes (according to OBJECTIF SÉCURITÉ).

Also a good german article: http://www.n-tv.de/technik/Passwoerter-werden-unsicherer-article10092261.html

A good english article: http://www.deloitte.com/view/en_GX/global/industries/technology-media-telecommunications/tmt-predictions-2013/tmt-predictions-2013-technology/9eb6f4efcbccb310VgnVCM1000003256f70aRCRD.htm

Having that in mind it is time to consider different logon mechanism with extreme large passwords or two factor authentication.

The Aloaha Smartlogin is one Credential Tile (or Gina on XP) hosting a large number of new authentication methods:

1. Traditional Smartcard Certificate Login via Kerberos (Active Directory required)
Any smartcard holding a certificate issued by the domain CA can be used as a two factor authentication token without even having to have or know a password. Obviously this works also via RDP

2. Smartcard Login via Credentials encrypted with the certificate of the Smartcard.
Basically Username, optional Domain and Password are encrypted with the certificate. This encrypted token is used to authenticate the user. Passwords can be chosen extremely long. The user just needs to remember the PIN of the Smartcard. Aloaha will then use the smartcard to decrypt the extreme long password to pass it to the machine for authentication.
This mode supports Active Directory but does NOT require it. It also works via RDP.
Since there are no requirements on the certificate this mode is suggested for e-Health Cards, ATM Cards, Company Cards, etc.

3. Credentials saved on a PKCS11 Token.
Even here the user can choose an extreme long password. He does not need to remember it since it is stored inside the PKCS11 token. The user only needs to type in the PIN of the token to enable Aloaha to read the extreme long password to pass it for authentication.
This mode supports Active Directory but does NOT require it.

4. Credentials saved on a plain memory card
In this mode it is possible to use very cheap i2c memory cards. Certificates or Active directory are not required since no RSA encryption is involved.
Passwords are NOT saved on the memory card but only a hash. This hash will be compared to the inputted passwords hash and only if they match a logon is granted. So even if someone manages to crack a password he would still need the matching card to get access to the machine.

5. Credentials saved on a plain USB Memory Stick or mobile phone.
This methods works similar to the PKCS11 mechanism BUT cannot be considered as secure as the methods 1-3. It will work ONLY at the console since RDP sessions are NOT supported. This mode is freeware and does not require any license.

6. Custom Plugins
The Aloaha Smartlogin supports custom plugins so that customer are able to create their own authentication mechanism.

The evaluation version can be download from http://www.aloaha.com/download/smartlogin.zip

Your evaluation key is: 8CAAEF6D4-C9D980551-03136DBC5-438EADB32-AC1567A23-2E1E2256E (two weeks from today)
More information can be found on http://www.aloaha.com/smartcard-software-en/aloaha-credential-provider.php and of course in our blog on http://blog.aloaha.com/category/aloaha-smartcard-software-en/aloaha-smart-login/

SecureSIM: Aloaha secureSIM

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

The Aloaha Credential Provider supports a broad range of security token. Depending on the token the tile itself looks different.

PKI/Kerberos Cards are cards which are nativly supported by windows or via 3rd party smartcard middleware. Furthermore the machine has to be a member of a domain.

For Aloaha to detect a card as PKI/Kerberos Card it has to be registered as such in <installdir>Userpass.ini

[Kerberos]
aloaha_3BDB18FFC080B1FE751F035A43372E352052455620416F=1
Aloaha Cryptographic Provider=1
Datakey M 330=1
eToken Base Cryptographic Provider=1

The Smartcard Name or the Middleware Name has to be set to 1 for Aloaha to detect the token as supported PKI Token.

Once Aloaha detects a card as PKI Token the tile looks like below:

Aloaha Credential Provider PKI Tile

For all other logon token the tile looks generic like:

Aloaha Credential Provider Generic Tile

In some cases the Username is NOT required since the token itself contains already the username. In that case the field can be just left blank. It is also possible to hide the Username field if in <installdir>Userpass.ini the following keys are set:

[Generic]
DisableUserName=1
EnableUserName=0

After a reboot the tile will look like:

Aloaha Credential Provider Tile without Username

The Aloaha Smart Login Supports a broad range of Logon Tokens. For example memory cards or sticks, PKI or Kerberos Smartcards, PKCS11 token, etc.

For that reason it is not really required that Windows shows all logon tiles as below:

Windows Logon TIles

During the start of the Aloaha Service it checks some settings in <installdir>Userpass.ini. If you set AllowUP=0 the Aloaha Service will disable ALL other Credential Tiles:

[Generic]
AllowUP=0

The result will look like:

Aloaha Credential Tile only

The Aloaha Smartlogin GINA supports a broad range of logon token. For example Memory Sticks, Memory Cards (i2c), PKI Smartcards and also PKCS11 Token.

Depending on the token detected the Aloaha GINA will look different.

On http://blog.aloaha.com/2012/08/14/aloaha-smart-login-gina/ we explained already PKI/Kerberos Cards.

Here we will explain the GINA for all NON PKI or Kerberos Smartcards.

Per default the screen will look like:

Aloaha SmartLogin Gina any Token

In case the Domain/Username field is empty Aloaha will guess the Domain/Username automatically. With many tokens that is possible since the token itself contains the Username.

For that reason we made it easy to disable the Username Field completly. Just open the <installdir>\Userpass.ini and edit the required entries as shown below:

[Generic]
DisableUserName=1
EnableUserName=0
AllowUP=1

After a reboot the result looks like:

Aloaha Smart Login Gina no Username