 |
Authenticator - Sign Files. Hash Files. Verify Digital Signatures. Generate Public-Private Key Pairs. Verify and Be Verified - Be Safe Online, Make Your Website Trusted.
|  |
|
|
| This section discusses the Authenticator module. Section contents: |
|
 - Using the Authenticator Module
|
Introduction to the Authenticator module |
The objective of the process of authentication is to confirm or deny that an entity is real or genuine. Authentication is most commonly used to confirm or deny identity,
authenticity and integrity. An example of when identity authentication is required is when receiving an email. Provided that the content of the email does not raise immediate
doubts, most people authenticate the sender implicitly by comparing the email address of the sender with the email address that they expect to see if the email was indeed sent
by the authentic sender. However, this is the same as authenticating the sender of a conventional letter by the return name and address on the back of the envelope. It is flawed
logic. Obviously, one can place whatever return address they like on a conventional letter. The underlying erroneous assumption that many people make is that the declared email
sender is always the mail box from where the email was sent. The reasons for this assumption may be routed in the fact that most people simply use mailing software which hides
the internal operations of the mail server, and so people assume that it is somehow an automatic and secure process void of external inferences. Therefore, it is important to
authenticate emails containing private or sensitive content to a sufficient degree. A simple, effective step-by-step mechanism on how to exchange information online safely is
described in the Exact Steps to Exchange Emails
Safely protocol.
The protective power of authenticity verification can be also used to confirm that a file was created by the entity that claims to have done so. For example, when installing software
on Windows Vista and above, the user is shown a window which either confirms the authenticity of the installation package or states that the software origin cannot be established
i.e. authenticated. An excellent example of direct benefits brought about by authentication is when it is employed to digitally sign the testimonials placed on a website. This allows the visitors of
the website to automatically verify the testimonials with the referee and be sure that they are authentic and genuine, which raises the level of trust in the website multiple times.
This simple but important mechanism is explained step-by-step in the How to Make Your Website Trusted protocol.
There are other cases when it is important to establish the authenticity of a data file or document. Sometimes the authentication process may deal with establishing the integrity of a file,
rather than its origin. For example, that a file has not been corrupted by errors during transmission. The authentication process is simple and is generally some variation of the following three steps:
- Create a signature.
- Supply reference, this may be a public key or a hash code; in some particular cases this may also necessitate the use of a digital certificate.
- Verify the signature using the reference.
Depending on the authentication objectives and circumstances one would use these steps in a suitable fashion so that authentication can be achieved.
The Authenticator module can be used to easily confirm the identity, authenticity and integrity of entities such as those described above.
|
The Authenticator module functionalities |
|
|
Authentication Principles |
Definitions and Naming |
In order to simplify this discussion we will introduce the following definitions:
Definition: Authenticator is the entity that uses the process of authentication to verify the authenticity of another entity.
Definition: Authenticatee is the entity whose authenticity (or identity) is being verified by the authenticator.
Definition: Private Key is a file with special content produced by a special algorithm which is used in certain authentication and encryption processes. You can generate a new private key using Act On File at any time.
Definition: Public Key is a file produced from a particular private key and is also used in the same processes of authentication and encryption as its complement private key.
Note: Although the authenticatee role may seem to be passive, the digital authentication process requires the authenticatee to create and appropriately supply a reference.
Note: There are different types of public and private key pairs, respectively used for authentication and encryption. In this document we discuss authentication.
|
Create and Supply Reference |
The first thing that needs to be done before an Authenticator is able to authenticate the authenticatee is for the authenticatee to create an appropriate reference and supply it to anyone
who would later authenticate the authenticatee using it. Most commonly the reference is one or more of the following:
- Public key;
- Hash;
- Digital certificate – a digital certificate is issued by a third party on behalf of the authenticatee.
Note: A digital certificate is only required when there is no authentic channel to supply the authenticatee's reference (public key) to the authenticator(s) directly.
The digital certificate is essentially a reference issued on behalf of the authenticatee by a third party substituting or complementing the authenticatee's own reference.
The digital certificate issuer should be trusted by all other parties and have secure or authentic channels to all other parties. Thus, the process of direct authentication
of the authenticatee by the authenticator is replaced by two steps; indirect authentication in which (1.) the authenticatee is authenticated by the third party and (2.) the
authenticator either simply trusts the results from (1) or further authenticates them. The process of authentication using digital certificate, i.e. using a third party, is
not recommended if an authentic channel between the authenticatee and the authenticator(s) exists. Consider the example of a digital certificate being used for signing software:
if the software is downloaded from the vendor website, in respect to authentication, there is absolutely no need for a digital certificate as it adds no value. However, if the
software is downloaded from a fourth party software-download-hosting website, the digital certificate does add value and guarantees that the downloaded software was indeed created
by the vendor stated on the digital certificate, provided that both the authenticatee and the digital certificate issuer can be trusted. Obviously, simply downloading the software
from the authentic source has far more authenticity than trusting a digital certificate. Digital Certificates are therefore only meaningful when there is no authentic channel to
exchange the reference between the authenticatee and the authenticators. An authentic channel is defined as a means of data exchange resistant to, or without tampering. A secure
channel is defined as a means of data exchange resistant to, or without both tampering and interception.
Act On File does not work with digital certificates since, as explained earlier, they bring large overheads and limited benefits, although they do have their place when a direct authentic
channel cannot be established but indirect is possible. However, Act On File accentuates on the direct use of authentication using a public and private key pair, for which the existence of
a direct authentic channel between the entities is necessary. Establishing a direct authentic channel can be very simple, but in some specific cases it may not be possible. Usually, but not
always, if an indirect authentic channel does exist, then a direct authentic channel may also exist. This is especially true if at least one of the sides is able to accommodate some flexibility.
Establishing an authentic channel simply consists of finding a means to transfer the reference from the authenticatee to the authenticator in a way that the authenticator is certain that the
authenticatee supplied the reference (and not an imposter) and the reference has not been in any way corrupted. There is always a degree in that certainty which is usually implicitly adjusted
to reflect the required level of security. Some of the multiple possible examples include:
- Placing a hash (reference) on a website. To verify that a file has been downloaded without an error, many download websites display a hash code which is a long
number computed from the contents of the file. The authentication in this case consists of verifying the integrity of the downloaded file, i.e. that the file has been downloaded without
errors. By simply displaying the hash code (reference) of the file on the download page, the website establishes an authentic channel to every visitor. The visitor can download the file
and use the hash code (reference) that the website displays, and compare it to the hash code of the downloaded file which they compute using Act On File. If the two hash codes match then
the file is authentic. In this case, it means that the file integrity is whole. To reiterate, the act of displaying a reference on a non-forgeable location such as website is an act of
establishing an authentic channel, with the respective degree of trust.
- Placing a public-key (reference) on a website to be downloaded by the visitors is also a way of establishing an authentic channel although with different
objectives than the above example. To add additional certainty, one may also want to place a hash of the public key along it, so that the visitors can ensure that the integrity of
the public file has not been corrupted during the data transmission while being downloaded.
- Exchanging a public key, hash or other reference via physical exchange, for example meeting up and exchanging the files.
- Sending the reference by an authenticated transmission, e.g. authenticated email. For example, if you are able to authenticate the origin of an email, you may transfer a secondary
reference and thus establish a second authentic channel. For instance, you may negotiate using a special password in the email which the authenticator can use to establish the authenticity of the origin of the email.
Note: A certain degree of trust must always be accepted. For example, even when exchanging physical devices, each side must trust that the other side did not make a mistake and gave them the correct reference.
|
Sign Entity - Digital Signatures |
The digital signature of a file ("signed file") is another file which is derived from it using a special algorithm and a private key. The signature is a small file with a
typically constant size dependent on the algorithm and the size of the key that were used in producing it. The idea is that due to the nature of the used algorithms and private key, there is a unique bond between the
signed and the signature files. This bond could be verified only with the original private key used to produce the signature, or with its complementing public key. Thus, if the recipient of a message receives a data
file and its signature, then using the public key (reference) of the sender (which they obtained through an authentic channel as discussed above), they can verify whether or not the file is authentic and its integrity is intact.
Using the Sign Files functionality of Act On File, one first creates and saves a public and private key pair. If they already have a private key, they can simply import it.
They then proceed to sign the selected files by using the Sign Files functionality, generating the signature files. Depending on the destination mode, the signatures may be
deposited in an appropriate location on a drive or be appended to each respective signed file. The signed files and signatures are then ready to be transferred to their destinations. Once transferred, the recipients
can then use the reference that they were given (the public key complement to the private key used in the production of the signatures) to verify the origin and integrity of the signed files. Any change in a signed
file or its signature will result in a negative or failed result from the verification process using the reference.
|
Verify Entity |
To verify a file, one needs to have the file, its digital signature and the public key complement to the private key used for generating the signature. Use the Verify Signatures
functionality of the Authenticator module of Act On File to verify the authenticity (origin and integrity) of the authenticated file.
In practice, this process can be used to authenticate emails by signing files and attaching them and their signatures (appended to the original file or as separate attachments) to the message. The message recipient then
authenticates the files using the public key of the sender (perhaps available for download from their website or otherwise authentically supplied). Note that this process authenticates the attachments and not the email
as the attached authentic file and its signature may have been intercepted and misused by imposters. To authenticate the actual message, the signature must either be included as text within the body of the message, or
be added to the end of it.
Besides email authentication, there are many other scenarios and cases where authentication using the above principles and mechanisms could easily and successfully be used ensure the security, safety and smooth performance
of many systems. For example, one may authenticate legal entities, people, electronic and digital systems, messengers, data stored on media and other devices, data communication etc.
|
|
