Encryption Methods - Part 2

More PAM:

In Linux PAM provides for separation of authentication tasks into each of four groups for management: Validation, Identity, Password, Session. Each of these phases of user management can be described in a simple manner.

Validation: Account validation by methods such as time of day, account expiration or actual permission to access system resources or services.

Identity:   Verify a user’s identity by checking a password or other secret information. This information can be sent along to other processes for further validation such as Kerberos or RADIUS servers.

Password: Handle tasks of password updates and are most often tied to the Identity modules and are used to enforce password complexity and strength.

Session:  Each session has a beginning stage and an ending stage and actions for each are defined using the session modules. Actions also performed after the user has logged into the system or service are performed by these modules.

SSL:

Secure Sockets Layer is an encryption method which was developed by Netscape way back in 1995 to provide security over the Internet and supports multiple encryption protocols for both client and server authentication. SSL creates a secure channel of data over the transport layer and encrypts various sorts of data types.

The most commonly recognized use of SSL protocol is the HTTPS or encrypted web page standard. This provided confidentiality, authentication, integrity and non-repudiation and supports multiple key management utilities and encryption algorithms between each party (i.e. web browser and server processes), but it has been supplanted by the much more secure TLS.

SSL was a step towards making the Internet secure, but attacks have continued and more recent exploits such as POODLE(1) have forced Linux distributions and web browser makers to disable even version 3.0 of SSL.

TLS:

Transport Layer Security (TLS) has replaced SSL as the encryption of choice as it is much more secure than SSL and provides exceptional privacy through symmetric cryptography for data encryption.

TLS 1.1 was adopted as the standard through RFC 4346 in April 2006 and TLS 1.2 via RFC 5246 in August 2008 and was updated in March 2011 via RFC 6176. Each version of TLS has built on the original SSL specification(2).

The primary advantages of TLS is that keys for the session are generated with each connection and are based on a shared secret negotiated at the start of the session. This means the server and client negotiate the encryption algorithm and cryptographic keys before and data is transmitted between them. This transmission between both systems or services cannot be tapped (eavesdropped) even by attackers who might be performing a man-in-the-middle on the session. No attacker can modify the traffic without being detected.

Browser Encryption:

Modern web browsers such as Google Chrome and Firefox are especially adept at notifying the user of such attacks by indicating the status of a connection with a broken lock in the address bar and a pop-up window indicating failed encryption session (3).

Each session also has integrity because each message sent down the wire includes a MAC (message authentication code) to prevent loss, alteration or other data problems during transmission.

Web servers today also utilize public-key-crytographic keys authenticated and verified by a third party such as Thawt, Verisign or LetsEncrypt known as a CA (Certificate Authority). These verified or trusted parties insure communications for e-commerce, banking, etc which in turn protect the very fabric of much of the modern world.

Perfect Forward Secrecy:

TLS can, when properly implemented, provide forward secrecy to ensure that any disclosure of encryption keys in the future doesn’t allow the data from past TLS encrypted sessions to be decrypted. This means any future compromise or disclosure of long-term cryptographic keys doesn’t compromise any data previously protected by those keys. Data remains encrypted even if it were captured and stored by Nation States for unwarranted spying (4).

More to come in part 3:

SMIME, IPSEC, & SSH

1 ref: https://en.wikipedia.org/wiki/Transport_Layer_Security#POODLE_attack

2 ref: https://en.wikipedia.org/wiki/Transport_Layer_Security

3 ref: https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers

4 ref: https://en.wikipedia.org/wiki/Forward_secrecy

Encryption Methods - Part 1

Password Encryption:

We use passwords everywhere these days. From your run-of-the-mill desktop login to Facebook and beyond, we just can’t get away from passwords (or so it seems).

Try working at any business with any level of security control and you understand just how complex our passwords have must be to provide any level of security.

Linux primarily uses the DES encryption algorithm to encrypt your passwords which are stored in the /etc/shadow file. When logging into your system, the password you’ve typed is encrypted on the fly and compared against the one stored in your system’s /etc/shadow file. If they match, you’re allowed to login. The advantage of this encrypted one-way function is it shouldn’t be possible to reverse the encryption and get to the password from the contents of the /etc/shadow file.

Physical access to the system however, can allow an attacker to use one of a multitude of tools like John The Ripper, Brutus, RainbowCrack,etc. to crack your password if it is not sufficiently random. There are great live Linux ISOs with a plethora of attack tools such as these - Kali Linux and Black Arch are but a couple of examples.

Nothing to hide?

Even if you have nothing to hide, having encryption helps protect your privacy and the privacy of other people from bulk surveillance or from rogue software/malware. Even Edward Snowden used GPG to uncover the secrets of the NSA.

PKI:

Public-key Cryptography uses private and public keys for encryption/decryption of messages (via PGP). The Public key can be used by one party to encrypt a message and return it to the owner of the public key (also the private key holder). This message can be decrypted only by the party holding the private key. This common method is used by Governmental agencies and the military to secure messages from enemies or the public with keys stored on a PKI Token or Common Access Smart Card.

PGP and GPG:

Pretty Good Privacy is fully supported on Linux distributions, however some countries (the USA) limit using such methods and have laws against export of the technology.

GNU Privacy Guard (GPG):

Recent Linux distributions come with GnuGPG support built-in. GPG is the completely open and free encryption standard based on the OpenPGP standard & uses algorithms which do not have export restrictions.

gpg2 is  the OpenPGP part of the GNU Privacy Guard (GnuPG). It is a tool to provide digital encryption  and  signing  services using  the OpenPGP standard. gpg2 features complete key management and all the bells and whistles you  would  expect  from  a full OpenPGP implementation -(quoted from gpg2 man page).

Using GPG is a simple matter in Linux and even email clients such as Silpheed-Claws can take advantage and protect your email from prying eyes.

PAM and 2-factor:

With the advent of 2-factor and external authentication programs or services (such as Google Authenticator), additional levels of validation of a user can be applied through PAM. No, not the biscuit pan spray, but Pluggable Authentication Modules. Adding a simple PAM module to your system with a scripted installation of the Google Authenticator program can easily secure your system’s local or remote login (ssh). This additional level of authentication uses PAM libraries and timing to verify the code provided in an app on a phone (or computer system) matches that typed into the authentication dialog.

Part 2 - coming soon:

SSL, TLS and beyond...