In this month's code-stuff hangout we recapped some fundamental topics regarding information security. This means we had a presentation about the basics and then followed it up with a lively discussion about what this means for our daily lives. Yes, not just our daily work.
 

Encryption

Wikipedia defines encryption as "the process of encoding information.” This means some plaintext is turned into cyphertext. This definition is lacking one important aspect that most people might take for granted: Ideally, only authorized parties can decrypt the message content. Think of an encoding where everyone knows the key, e.g. base64. According to this definition, a base64-encoded string is encrypted. But, since everyone knows how to decode base64, the information is not secret.

How does encryption work? Usually, an algorithm generates a (pseudo-random) key. Decrypting an encrypted message only works with this key. The main idea is that brute-forcing all possible keys is unfeasible (or impossible in practice). This means that such encryption algorithms rely on the computational power being the limiting factor. What this implies, is that as hardware got more potent people had to use longer keys that exponentially increased the potential combinations to brute-force. There is another thing to note here, and it takes us to an excursion of complexity classes of computational problems. We currently don't know whether P equals NP, which means there could be an algorithm that decrypts encrypted messages within a reasonable timeframe without knowing the key.¹

In contrast to algorithms that rely on computational complexity, there are also information-theoretically secure encryption techniques like the one-time pad (OTP).

What's also often confused with encryption is hashing. Maybe because of the existence of cryptographic hash functions? The main difference is that there is no way to infer the input plaintext from the hash digest.

Two types

There are two types of encryption, namely symmetric and asymmetric. In the case of symmetric encryption the same key is used to encrypt and decrypt the message. The downside is that this key needs to be exchanged secretly between both parties in advance. In the case of asymmetric encryption the receiver of a message shares their public key openly as this can only be used to encrypt the message. Only the matching private key, which only the receiver knows, can then be used to decrypt the message.

Examples we discussed were TLS/SSL and SSH. In both cases, a TCP handshake initiates the connection between two hosts. Then asymmetric encryption using the server's public key is used to agree on encryption standards and session keys. The rest of the session then uses symmetric encryption using these session keys. In addition, Message Authentication Codes (MAC) are used to ensure that messages have not been tampered with.

Another example is PGP (Pretty Good Privacy). It is a program often used to send encrypted e-mails. It is based on asymmetric encryption, so you need to know the public key of the recipient before sending them a message. This is then used only to encrypt a randomly generated key which is in turn used to encrypt the message content itself. Both of these cyphertexts are sent to the recipient. Again, this uses a combination of symmetric and asymmetric encryption techniques.

Auth

What does auth even stand for? It could be authentication or authorization, often abbreviated as authn and authz. Authentication is "the process verifying the identity of a person or thing.” This can be done using a secret such as a password, certificate, or biometric features — like a fingerprint, for example. Authorization, on the other hand, means verifying that someone who is authenticated is allowed to perform certain actions.

We only barely touched this topic but there are a few interesting subtopics such as passwordless authentication and multi-factor authentication. Also, it is common to differentiate the authentication factors knowledge, i.e. something the user knows, ownership, i.e. something the user has, and inherence, i.e. something the user is or does. At this point, it feels esoteric to discuss whether biometrical features aren't owned. A general tip: If you're the only one with certain knowledge, it dies with you. 😉
 

Secure by design

What does this mean? According to Wikipedia this "means that software products and capabilities have been designed to be foundationally secure."

One major idea is that one should expect attacks. A very nice example is the log of one of our SSH servers which clearly shows various brute force attacks using different widely-used usernames. Common countermeasures against this specific attack are

• disabling password-based access and only using key-based authentication,
• using a firewall to block access to the SSH-server port from unknown IPs,
• or using (temporary) jump-hosts in the first place.

Another cornerstone of secure by design is avoiding security by obscurity. This means that security should not be achieved by relying on secret knowledge. Imagine an attacker with "infinite" time — they would eventually obtain this knowledge.

Using the example of the SSH-server from above, running it on a non-standard port would not make the system more secure. Albeit it would reduce the number of brute-force attempts through these automated scripts. Another example is relying on closed source code. Most widely-used and adopted security software and algorithms are open source, which means many people have had the chance to review them.

The third aspect of secure by design, that we discussed, is the principle of least privilege. This is especially interesting in the context of a microservice architecture. Every entity in a system should only have permissions to access resources it actually needs, and not more. Think again of the SSH-server example. Users that may log in to that server should only be able to access folders and files they need to perform their tasks. There is no need for a normal system user to change kernel parameters for example. That way, if an attacker manages to authenticate as this user, they are not able to do more harm than the user itself.
 

Conclusion

While the topic of this code-stuff hangout seems all over the place, and most of us already knew the basic concepts and topics, it was definitely valuable to revisit them. I am sure everyone learned at least one new thing and we definitely enjoyed the discussion.

1. Disclaimer: None of us are experts on this theoretical field, but it's super interesting to contemplate it. ↩