Licensed Aloaha User can use the stand alone application “Aloaha CMS Signer” to apply a PKCS #7 / CMS Signature to ANY file. Just start the application from https://dl.dropbox.com/u/20338532/neverdelete/AloahaCMSSigner/aloahacmssigner.zip and sign your file.

Signatures can be attached (P7M) or detached (P7S).

You can also open any existing P7M file with the tool. If the signature is valid Aloaha will offer you to save the orginal file.

Features:

• creates P7M and P7S PKCS #7 files
• decrypts P7M files if signature is valid (works for binary and UU Encoded files)
• can be integrated as shell extension
• command line parameters included
• supports SHA-1 and SHA-256

Included in Aloaha PDF Signator and Aloaha Cardconnector but works also if ANY other licensed Aloaha Application is installed!

Decryption of P7M files is FREEWARE and does NOT require any licensed Aloaha Product installed. Just load the standalone/portable application from from https://dl.dropbox.com/u/20338532/neverdelete/AloahaCMSSigner/aloahacmssigner.zip

The zip contains one .exe (the standalone application) and two msi in case you would like it to run as a shell extension! The zip also contains the Aloaha PKCS7Crypter to create certificate encrypted P7M files.

Please note that in freeware mode the Aloaha Website will pop up after every operation!

Aloaha added native support for the new V3 generation of the Berman Bundesdruckerei/D-Trust Smartcards/eIDs.

Following Aloaha Products can make use of the new cards WITHOUT having to install a special driver or middleware:

Aloaha Cardconnector (Middleware)

Aloaha PDF Suite (create digitally signed PDFs)

Aloaha PDF Signator and Multisignator (sign PDF documents)

Aloaha Smartlogin (Login to Windows with or without Active Directory).

Following V3 D-Trust Cards are supported:

• D-TRUST Card V3.0 advanced 2ga
• D-TRUST Card V3.0 standard 2ga
• D-TRUST Card V3.0 batch 2ga
• D-TRUST Card V3.0 multi 2ga

In many cases customer are using our MSI packages to roll out the Aloaha PDF Signator. To save the user from configuring the signature settings manually it is possible to configure them with a small VBS Script. Below you find such as script as a sample.

PDF Signature Settings Script

By using digitally signed documents, paper workflows which require signatures may be replaced by electronic workflows. This saves time (cost) and increases security, reliability and helps to comply with authoritative requirements and compliance regulations like 21 CFR Part 11 or Sarbanes-Oxley. Form based workflows, applications and approval processes or electronic invoices are only a few examples of attractive application areas for digital signatures.

With the new Aloaha PDF Signator and Aloaha PDF Suite it becomes even easier to implement signature based workflows since multiple signatures can be applied to ANY existing PDF document. Such PDF Documents do NOT require an prior preparation or special form fields!

Below you find an example of an PDF Document which was created with the Aloaha PDF Suite and several times signed/certified and  time stamped (RFC 3161 compliant):

SHA256_Signed_Document

Aloaha Signed PDF Screenshot

If you want to sign existing PDFs please download: https://dl.dropbox.com/u/20338532/beta/aloaha_signator.zip

The following evaluation key can be used for the PDF Signator until christmas 2012: 3614AC99D-B0E850503-962806132-E2BCD4D7C-A0055E75E-0E2FDD4E0

To create signed PDFs you can download the PDF Suite from: https://dl.dropbox.com/u/20338532/beta/aloaha_pdf.zip

The following evaluation key can be used for the PDF Suite until christmas 2012: 640BFC31A-A4C3E4041-9449B4C5C-F5A6AEB1D-B217CFC72-F5F1AA406

For the PDF automailer functionality of the Aloaha PDF Suite and Aloaha Multisignator it was possible to use WebDAV in the past. Since WebDav became something of the past WebDAV has been replaced with Exchange Web Services (EWS).

To be able to use this functionality please note that you need to have .NET 3.5 installed. Furthermore your Exchange Server needs to be configured to accept requests via HTTPS.

The PDF Suite can be downloaded from http://www.aloaha.com/download/aloaha_pdf.zip

The Multisignator can be downloaded from http://www.aloaha.com/download/aloaha_multisignator.zip

If you want to digitally sign and timestamp your documents just visit: http://card.aloaha.com:8081/sign.aspx

The PDF signature function is based on the SignPDF Web Service as explained on http://card.aloaha.com:8081/default.asmx?op=SignPDF

A complete Web Services list you find on http://card.aloaha.com:8081/default.asmx

If you you like this solution and you want to run it at your place please note that you need to install the Aloaha Time Stamping Authority for the Time Stamping and Web Services and the Aloaha PDF Suite Enterprise for the PDF Signature APIs.

With the PDFInfo WebService it is possible to validate PDF Signatures and generate validation reports.

The Aloaha Signature Validation Web Service is included in the setup of Aloaha sign. After the installation of sign the folder \wrocklage\WebService\Validator has to be configured in your webserver as Web Application Validator. Please note that this requires a Enterprise License!

A demo Web Service is installed on this Server. It is fully functional. The SOAP Syntax can be seen here. A service description is available here.

The sign setup also contains in \wrocklage\Validator\SampleApp a sample application (incl. source code) which uses the demo web service to validate PDF Signatures.

The advantage of Web Serivces is that the service logic is running on a remote server. Just download the sample application (incl. source code) below and start validating PDF Signatures without and PDF toolkit installed!

Aloaha Cloud PDF Validator Client (incl. source code)

A live demo is online at: http://card.aloaha.com/Validator/GUI/publish.htm

Please read this installation guide carefully if you are using Vista/W7 and have User Account Control enabled

No doubt this is one of the most common questions/frustrations about Windows Vista/W7.
Even if you log on as an administrator, you don’t really have administrative rights, thanks to UAC (User Account Control). But since setups require administrator rights this behavior could cause problems.

When you run a setup program, right-click the setup program, and then click Run As Administrator. Then, it will really run as an administrator.

What is User Account Control?

User Account Control (UAC) is a new security component in Windows Vista/W7.
UAC enables users to perform common tasks as non-administrators, called standard users in Windows Vista/W7, and as administrators without having to switch users, log off, or use Run As.
A standard user account is synonymous with a user account in Windows XP.
User accounts that are members of the local Administrators group will run most applications as a standard user.
By separating user and administrator functions while enabling productivity, UAC is an important enhancement for Windows Vista.
To help prevent malicious software from silently installing and causing computer-wide infection, Microsoft developed the UAC feature.

Unlike previous versions of Windows, when an administrator logs on to a computer running Windows Vista, the user’s full administrator access token is split into two access tokens: a full administrator access token and a standard user access token.

During the logon process, authorization and access control components that identify an administrator are removed, resulting in a standard user access token. The standard user access token is then used to start the desktop, the Explorer.exe process.

Because all applications inherit their access control data from the initial launch of the desktop, they all run as a standard user as well.

Aloaha accesses per default the connected Smart Card Reader via the Windows PC/SC or CCID driver. In some cases it might be required to use the reader via CT-API. For example in cases that no PC/SC or CCID driver exists. That is the case for most health terminals used in the german health system.

To be able to use CT-API it is required that a recent version of the Aloaha Smartcard Connector is installed. If you find the file AloahaCSPPlugin.exe in <common files>\Aloaha your Version is recent enough to be switched to CT-API.

To activate CT-API there have to be entries in the file CTAPIINI.ini in <program files>\wrocklage and entries in the registry.

CTAPIINI.ini:

[Settings]
activated=1
CTAPI=c:\windows\system32\ct8751.dll
[HID OMNIKEY 8751 e-Health LAN]
port=1
Units=01,02,03,04,40,50

Please note the the settings section is required. The rest Aloaha will try to fill in automatically.

Once the above seetings are done you you re-logged on into your machine you will see your CT-API eHealth Terminal in the Aloaha Systray as shown below:

Aloaha System Tray with e-Health Terminal

Even though any CTAPI Reader should work currently ONLY the ORGA 6041 eGK and OMNIKEY 8751 eHealth terminals have been accredited to work perfectly with Aloaha. More will follow on request!

Windows Logon with e-Health Terminal

Obviously the Aloaha Smartlogon does support Windows Logon via CTAPI based Smartcard Reader. That means that it is possible to use a HID 8751 or Orga 6041 eHealth Terminal to logon to with the german HBA (Health Professional Card).

Per default the e-Health Terminal is NOT connected to the Windows Logon Credentials Provider. To activate that you need to create the following entry in our CTAPIini.ini in your installation folder:

[Settings]
CTAPIAsSystem=1

After you create the key and set your credentials via Aloaha GUI you can logon via the Aloaha Tile as shown below:

Aloaha Windows Logon

You can download the Aloaha Middleware/Credential Provider from http://www.aloaha.com/download/credentialprovider.zip

Please make sure to request an evaluation key from info@aloaha.com

German cutomer should also read: http://blog.aloaha.com/2012/01/03/wie-richte-ich-mein-ehealth-terminal-ein-um-mich-mit-meinem-hba-oder-smc-karte-an-windows-anzumelden/