Short Bytes: Digital security is always a hot topic, but its growth is accelerating. In order to implement security, you need to understand security. But in order to really understand it, you need to start with the fundamentals — Privacy, Authentication, Integrity, and Nonrepudiation.
Security is a trade-off, there’s no denying that. Security makes things slower, more complex, less convenient, and sometimes confusing. That’s why they say security is a pain, but what exactly does it mean? The acronym PAIN is used for the four components of security, Privacy, Authentication, Integrity, and Nonrepudiation.
Privacy
We all know and understand what privacy is. It’s protecting your information from peering eyes. But it goes a little further than that in the world of digital security. Privacy can mean anonymity in a world that tries to track everything you do. While each application has a different requirement of privacy, there’s a common thread — encryption. Encryption has been around for over two thousand years. It’s been used in almost every major war in the last several centuries. It’s clearly a very important aspect of security. So, what should you look for in an encryption suite?
- Peer reviewed algorithms
- Open Source software
- Open Source or Open Standard protocols
Peer reviewed algorithms have been mathematically examined by cryptanalysts for weakness and exploits. This is a must because a backdoor could exist or there could be some mathematical attack that the cryptographer was not aware of when they designed the algorithm. You want the software to be open source so that it can be audited and updated to address any bugs or security concerns. And finally, you want your protocols to be open source or based on open standards for similar reasons — they’re audited and continuously inspected because many people rely on them.
The trade-off with encryption is that strong encryption requires time to compute, meaning that there’s an additional delay before the data is ready for transmission or storage.
Authentication
Authentication is the process of determining that you are who you claim to be, much like how many collectibles come with a certificate of authenticity, in order to be secure you must prove your identity. Authentication can be tricky, especially when two parties are in mutual distrust, to begin with. We typically authenticate with a password in addition to our username, your password is what proves your authenticity. But passwords can be guessed or cracked. This is why it’s important to have strong passwords, or better yet, multi-factor authentication. Multi-factor authentication is much simpler than it sounds. It simply means that instead of relying on a password as the single authentication criteria, you have an additional criterion such as a digital token or fob that produces a numeric code for authentication. Email is often used as secondary authentication when passwords need to be reset, but this is only a half-measure. Many services have opted for using mobile phones as another authentication method. While this is safe and practical in theory, it is actually insecure due to SMS protocol vulnerabilities. That aside, it is an excellent example.
So, why don’t we just have like half a dozen factors of authentication for all of our accounts? Well, that would be because security is a pain. Imagine having to manage all those different factors. It would become quite the nuisance.
Integrity
A large part of secure communications is knowing that something wasn’t altered by an assailant before you received it. That means, you want to determine whether the information has retained its integrity. You should always assume that a channel of communication is insecure until you have proven it to be secure, and even then, it is difficult to detect when an attacker has obtained any amount of access to a channel. While an attacker might not be able to see all communications going over a channel, they can still attempt to alter data before it’s put on the wire. This is known as a “man in the middle” attack. By implementing a method to verify the integrity of the data, you can ensure that any altered information is discarded. This integrity check is usually done using hashes. The original message is hashed and then the hash is encrypted with a private key. This way, even if an attacker intercepts the message, and even if they possess the public key, they cannot encrypt the hash (which is expected to be encrypted) in such a manner that when decrypted, it will be equal to the hash of the altered message. This is a very effective way to ensure data integrity, even when poorer hash algorithms are used, like MD5, because the hash is always encrypted anyway.
If this whole integrity thing is so simple, why don’t we all use that, and wouldn’t it make for a good authentication method, too? Data integrity is simple to determine with hashes but you also have to determine the validity of the hash, so you could hash the hash, but then you’d have to verify the hash of the hash as well. Confusing, right? Instead, we use encryption to encrypt the hash so when decrypted with the wrong key, or malicious encrypted with the wrong key, it won’t match and we know it has been altered, or maybe just corrupted, but it’s still important to know. If public key encryption (or asymmetric encryption) is so great, why isn’t everyone using it? Well, because it requires infrastructure, so-called Public Key Infrastructure (PKI), and PKI leads us right into our next pillar of security.
Nonrepudiation
In a secured environment, everyone has authenticated which means everyone can be identified. We all know that we can’t always trust the people within our walls. So, even with a secure system, we could have an assailant among the users who can authenticate and participate on the secure channels. That’s a pretty scary thought. Instead of letting anyone just wreak havoc on the system without any consequence just because they’ve already authenticated, we use nonrepudiation. Nonrepudiation is conceptually the converse of identification and authentication. It is the ability to determine that someone did do something, even if they claim they didn’t, and furthermore, eliminate the possibility that it was someone else. As Sherlock Holmes said, “when you have eliminated the impossible, whatever remains, however improbable, must be the truth.” How do we determine that it couldn’t have been anyone else? Well, the same way we determine data integrity, by using Public Key Infrastructure. By enforcing the use of PKI to carry out certain tasks like administrative tasks, dealing with confidential information, or communicating instructions, you can make certain that every action can be tied to the person that performed it. Now, it’s quite possible that someone could steal another’s private key due to someone’s carelessness, so in addition to the key a second factor would be required, typically a password that decrypts the key (meaning the key is useless on its own). All of this ensures that in a secured system there is no anonymity, and without anonymity, there should always be a witness to the crime.
If Public Key Infrastructure is so great, why doesn’t every organization use it? Because it’s just another thing to manage.
PKI is the one single solution that can assist in all of the aspects of security. A PKI certificate is actually just a text file with a large amount of information. The typical contents of a standard X.509 PKI certificate are as follows:
- Certificate
- Version Number – This is incremented every time the certificate is expired (or revoked) and renewed.
- Serial Number – This is a unique identifier for the certificate on the system that created it, also known as the issuer.
- Signature Algorithm ID
- Issuer Name – This is the system that generated the certificate, also known as a Certificate Authority.
- Validity period
- Not Before – A ticket cannot be used before is predecessor has expired (or at least shouldn’t)
- Not After – A ticket has an expiration for security reasons, much like when a password expires.
- Subject name
- Subject Public Key Info
- Public Key Algorithm – This could be RSA or Diffie-Hellman.
- Subject Public Key – This is the key itself.
- Issuer Unique Identifier (optional)
- Subject Unique Identifier (optional)
- Extensions (optional)
- Certificate Signature Algorithm – The algorithm used when signing.
- Certificate Signature – This is the signature performed by the Issuer indicating its integrity.
Make sure to check out the link above this list to the Wiki page for X.509 standard certificates, which is where I got this full list, and there is much more information as well.
Obviously, there is more to security than just using PKI, like ensuring that you are using up-to-date software with security patches, anti-malware, and so on. But, with respect to the human aspect of security, which is often the weakest point in any organization’s security, all four PAINful pillars can be built using PKI.
For those who are interested in playing around with PKI themselves, be sure to take a look at GNUPG, an open source implementation capable of all of the above (except the server side portion). How many Fossbytes readers use PKI at work or for their programming projects? Let us know in the comments below.
Also Read: “10 Immutable Laws of Security” That Every Geek Must Know
