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.

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.

Based on the Aloaha M2M Terminal you can try now: http://malta.aloaha.com

You can send ANY X10 Command via the Aloaha M2M Terminal Web Interface.

For example to switch Plug B12 you need to send:

http://malta.aloaha.com?X:b:2:on or http://malta.aloaha.com?X:b:2:off

Ideally you use a Marmitek TM13 Transceiver as a gateway between the X10 Signals sent by Aloaha and the X10 Powerline. As X10 device you can then use any compliant X10 device. For example the Marmitek AM12G

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 function of adding form fields to PDF Documents is disabled per default in the Aloaha PDF Saver. To activate it please enable the edit value in in the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Aloaha\PDFSaver]
“edit”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Aloaha\PDFSaver]
“edit”=dword:00000001

You can download the evaluation version of the Aloaha PDF Saver from http://www.aloaha.com/download/aloaha_saver.zip

More details can be found on: http://www.aloaha.com/wi-software-en/aloaha-pdf-saver.php

Via the .ini file it is possible to activate many features. For example automatic retrieval of the current weather temperature. Insert the Yahoo WOEID of your city so that Aloaha automatically logs the temperature to PVOutput.org.

[Settings]
YahooWOEID=10645040

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/

Introduction

A microcontroller is a small computer on a single integrated circuit containing a processor core, EEPROM and a small amount of SRAM.

Basically more or less the same as a modern Smartcard!

Additionally a microcontroller comes with programmable digital and analogue input/output peripherals. Typically such peripherals include switches, relays, LEDs, small or custom LCD displays, radio frequency devices, and sensors for data such as temperature, humidity, light level etc.

A microcontroller can be considered a self-contained system with a processor, memory and peripherals and is usually used as an embedded system. Typical input and output devices include switches, relays, solenoids, LEDs, small or custom LCD displays, radio frequency devices, and sensors for data such as temperature, humidity, light level etc. Embedded systems usually have no keyboard, screen, disks, printers, or other recognizable I/O devices of a personal computer, and may lack human interaction devices of any kind.

Aloaha secureM2M

Based on our vast experience in Smartcard, secureSIM and security software development and due to the lack of comprehensive security solutions for M2M Terminals Aloaha is offering now a microcontroller based secure M2M Terminal.

Features:

• 8 digital I/O lines to switch relays, digital sensors, etc.
• 6 PWM signal lines
• 8 analogue input lines for sensors, etc.
• Connectivity via Serial Port, Quad band GSM/3G Modem, IR, RF, Ethernet, Zigbee, Bluetooth or Wifi
• Aloaha Software with embedded FTP, HTTP, Mail, SMS and TCP Socket Server/Clients
• supports AES, SHA1/256 and optional RSA via secureSIM or secure uSD

Digital I/O

• Capture, log and count digital input pulses
• Capture serial data from loggers, controllers and sensors
• Send digital input alerts, logs and counts via SMS, HTTP, email or FTP
• Trigger relays upon digital input events
• Monitor and log analog input (temp, flow, pressure, noise, gas)
• Send analog value set point alerts via SMS, HTTP, Email or FTP
• Trigger relays upon analog input set point

Interested to learn more about our new M2M Box? Please contact us at info@aloaha.com. It will be a pleasure for us to call you back to discuss your requirements.

secureSIM Presentation: Aloaha secureSIM

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 “Aloaha Time-Stamping Authority” is a cryptographic time stamping application that enables organizations or individuals to apply tamper-evident digital “Seals” to all forms of digital
information. It provides long-term and independent proof that the information existed at a particular point in time and has not been altered since.

The “Aloaha Time-Stamping Authority” provides Independently-Verifiable and Long-Lasting Proof of Electronic Record Authenticity

1. The “Aloaha Time Stamping Authority” can be used to meet a broad range of data integrity objectives, including safeguarding critical documents against tampering and alteration, proving the authenticity of records, protecting digitally based intellectual property, preserving digital evidence, demonstrating regulatory compliance, and ensuring litigation readiness.
2. An electronic signature does not offer proof of the time the signature was created. However, time is essential to determine the legal effects of a contract or any other document. This procedure is met by all existing Time Stamping Authorities (TSAs).
3. The Aloaha TSA application is compatible to both RFC 31614 and Microsoft Authenticode digital time stamping standard. The Aloaha TSA application enables users to protect the
   integrity and prove the authenticity of any form of digital data, including electronic documents and records, spreadsheets, web pages, digital evidence, emails, scanned images, video, audio, electronic health records, emails, photographs, source code, engineering and CAD diagrams, Xrays, audit logs, etc.
4. For electronic documents or any other form of digital workflows to be time stamped, users need to send the digest6 of the document to a Time Stamping Authority which then in return adds the time to the digest, signs and archives it and then sends the resulting secured digital time stamping token in form of a digital signature back to the user.
5. The content of the document to be time stamped does not need to be revealed to the Time Stamping Authority. The TSA processes only the digest7 of the document.
6. Current TSAs exist in the form of hardware appliances or are offered in the form of hosted services. The latter require that users register and authenticate themselves. The users are
   charged per each or bundled time stamps. The disadvantage is that such hardware installations and hosted processes are too complicated and expensive for single users or small enterprises lacking technological know how. The Aloaha TSA was designed to cater for disadvantages in the existing users economies of scale. Aloaha developed an application which is affordable and easy to use.

The innovative benefits of the Aloaha Time Stamping Authority Application

1. Aloaha’s Time Stamping Authority runs on site and is fully in the possession of the user. The various standard interfaces and auto configuration mechanisms used by Aloaha contribute to a user friendly application. Furthermore there are no running timestamping costs or related registration expenses. It is a windows service application running with a zero total cost of ownership (zero TCO).
2. Due to its unique time stamp request standard detection Aloaha is able to serve applications requiring different standards for time stamping. For example some office suites may request only RFC 3161 Time Stamps and others only Microsoft Authenticode Time Stamps. Aloaha is fully interoperable with different applications and protocols whether Aloaha’s or third parties’ software applications such as MS Office, Adobe Acrobat or SAP. This is a complete innovation in the industry.
3. Another advantage of Aloaha is that issued Time Stamping Tokens are not archived at a service provider but are archived and cross-stamped in the user’s own network. This grants the users full archiving control without depending on other service providers. Furthermore the user is able to publish all issued time stamping tokens to public and cloud libraries (such as Google) for verification and credibility. All this without overhead expenses. The full archiving control attribute is an innovative value to the user

With easy-to-use Aloaha desktop products users can use the Time Stamping technology without complicated configuration processes and without any running expenses involved.
Integrations into existing products such as Microsoft Office, Adobe Acrobat and SAP, commercially-available electronic content management systems is accomplished via scriptable
interfaces, local web services and a variety of software development kits. Organizations of all sizes can easily and cost-effectively use Aloaha to protect their critical digital information, no matter its format or where it resides.

Aloahas impact to existing processes.

Currently digital signatures become invalid once the underlying certificate expires. The validity of a digital certificate is always limited in time. Usually such time span is between 2 to 5
years. Additionally there is always the risk that a certificate has to be revoked with immediate effect following a key compromise or an algorithm change. In such cases the signatures issued by the related certificates are considered as null.

For example:
You sign a contract with your digital e-ID in September 2012. In October the e-ID was lost and replaced by a new one. In January 2013 a court has to determine if the electronic contract has been signed by the owner of the e-ID or a fraudster. Since the court cannot determine the time of the signature it cannot determine if the right owner of the revoked e-ID or the fraudster singed the contract. The contract is NULL. If the electronic signature would have been time stamped by Aloaha there would have been a non deniable proof of the signature time and thus the contract would be valid if signed before the lost of the e-ID.

The only way to secure a long-lasting proof of electronic records is to secure the used certificates against revocation and expiration. Until Aloaha’s innovation users could only archive such
documents to a tamper proof medium. Tamper proof mediums existed only in the physical world (in form of Paper, DVD and Microfiches9). This means that such users had to transfer such digital data to paper, DVD or Microfiche medium. Out of these three mediums only Microfiche is accredited as a long-lasting and auditable archiving medium. However the latter is not cost effective for small enterprises and individual users to use Microfiche as a medium to store records.

On the other hand paper needs good storage environment as it can deteriorate easily and data on DVD can be tampered and altered unless stored at a trustable environment (example: Notaries).

The Aloaha Time Stamping Authority comes also with an inbuilt web service to allow the user to connect other devices such as mobile phones, tablets, etc to the TSA.

Furthermore electronic archiving as used by the Aloaha TSA does not require any physical storage space; it is more cost effective and more ecological friendly.

Please contact info@aloaha.com for an evaluation version of the Aloaha TSA

With Aloaha it is possible to automatically apply a barcode to PDF via Hotfolder

1. Right click on your grey Aloaha System Tray Icon and disable “Interactive”. Please note that Admin Rights are required to de-activate “Interactive” and you need at least a server license.
2. Your Barcode Folder is <InstallDir>\BarcodeFolder or the one defined in HKLM\Software\Aloaha\pdf\BarCodeFolder.
3. In your barcode folder you need a file BarCode.ini. If it does not exist you need to create one. It will be created automatically with default settings when placing the first .pdf file in that folder.
4. With BarCodeType in the .ini file you define which type the barcode will have:
   1. Code39 (or Code 3 of 9)
   2. EAN-13
   3. Code128
   4. PostNet
   5. Interleaved 2 of 5
5. The value of the barcode will be the filename. With the plugin PlugInObjectName you can define a plugin to deliver a different barcode value.