In a normal access restriction system, the system merely demands a certain criteria be met, such as the knowledge of a passphrase before allowing access. The data itself is not actually protected. This is why booting from a secondary operating system on a computer allows an adversary to bypass all access restrictions on the primary system. This criteria can vary, from time variables, to location variables etc. The most common use of the time variable is on parental controls, where parents typically blacklist certain times of the day to restrict access to the computer or internet. In the case of encryption, it is substantially more complicated. In order for some data to be encrypted, there typically has to be three things present:
1. Algorithm
2. Encryption Key
3. Plain Data
An algorithm is essentially a set of predefined instructions. In this case, these instructions are used by the hardware processor to manipulate the plain data and cryptographically tie it to the Encryption Key. This ensures that the encryption, and only the encryption key will be able to reverse the processes done by the algorithm. This procedure is known as decryption. The data that results after manipulation by the algorithm is known as the ciphertext. This ciphertext is then fed into the same but reversed algorithm to decrypt the data. There are, however, exceptions to this typical framework of encryption. One such example is the ubiquitous process of hashing, found everywhere in the world of information security. In hashing, a plaintext is taken and fed through an algorithm. However, there is no encryption involved. The hashing algorithm merely does mathematical work on the data, which results in a hash. The uniqueness and practicality of hashing comes from the fact that any change in the data however small will result in a very different hash sum. This can be used to verify the integrity of files to ensure that they have not be altered during transit through a network, in an attack known as MITM. (Man-in-The-Middle). Also, a hash sum cannot be reversely fed through the algorithm: it is not possible to find out given the cipher text, what was the plaintext. Well known hashing algorithms used in the modern world are MD5, SHA and RIPEMD.
As for the typical encryption algorithms which use all of the three factors aforementioned above, prominent examples are AES (Advanced Encryption Standard) and DES (Data Encryption Standard). AES has superseded DES due to its cryptographic strength, measured here in terms of resistance to a brute force attack. (Trying every possible combination in the book). Cryptographic strength is also measured in bit size, as can be seen in AES coming in 3 flavours of 128, 192 and 256 bits. To crack a AES-128 key via bruteforce (with characters A-Z, 0-9), one will have to go through the trouble of trying a preposterous amount of 2^103 keys. The average desktop would still be sweating itself off long after we pass away. This is the power of AES if implemented correctly. However there are many possible ways to mucking up your implementation. Such a notorious way is through key generation. To generate encryption keys, one usually selects some characters from a pool of random data. Unfortunately, true random data is excessively hard to generate. Note that a computer merely listens to instructions given to it in the form of programs and algorithms: It is not capable of making any decisions on its own accord. Therefore, to generate true random data, we need to have a source of true physical randomness, something that your average computer user will not have access to. Such sources of random data include Quantum Vacuum Fluctuations, Atmospheric Variations etc. Therefore, we can only once again, use predefined algorithms to generate semi random which bear resemblance to true random number generators. These are termed 'Peseudorandom Number Generators'or PRNG as opposed to the physically based RNG. If one managed to successfully reverse engineer or otherwise, find a weakness in a PRNG algorithm. He/she would be able to predict with full certainty, any random number sequence given any interval of time. This results in the AES Encryption Key being compromised. The amount of randomness is termed 'entropy'. Therefore, to add entropy to your keys, software like GPG and the now-defunct Truecrypt usually have you move your mouse or type some gibberish into a text box. As the timing variations and position differences of typing and moving the mouse respectively cannot be replicated with much ease, it would suffice as an entropy permutation for the average user. Keep in mind that this method of permuting entropy into an encryption key will not immunize one from the advent of keyloggers or mouse trackers.
Now, the types of encryption algorithms may still be broken down into further groups, given the way they decrypt the data. These two groups are known as Symmetric Key Algorithms and Asymmetric Key Algorithms. For the math whizzes, you may already know the difference. Symmetric algorithms merely make use of the same encryption key to decrypt the data. Those were the type of encryption we have covered so far. (AES, DES) Then we have the backstage asymmetric key algorithms, which usually does not interface with the user directly; its operations are instead performed 'behind the scenes', as in the case of verifying the authenticity of the web pages we visit. The way asymmetric key cryptography works is slightly different from its counterpart. Instead of using the same keys for both decryption and encryption operations, different keys are used. A public key and a private key are generated, both of which, are mathematically linked in such a way that only the private key can decrypt data encrypted with the public key. As the names suggests, the public key can be freely distributed while the private key is to be safeguarded under high security. As a precaution, programs like GPG encrypt the private key with a symmetric key algorithm, in a process known as key wrapping. Common algorithms such as RSA, EC and the less secure DSA are familiar. Like symmetric key algorithms, RSA and DSA comes in the common flavors of 1024, 2048 and 4096 bits. EC comes into flavors of up to 512 bits. I once generated a ridiculous 20480 bit RSA key which nearly caused my computer to crash while signing in to my SSH server. From here, we can see the trade-offs of computing power and security. This is also the reason why the smaller but secure EC is prefered over to RSA. Apart from direct and bulk encryption of data, asymmetric key cryptography is commonly used to exchanged symmetric key data securely, as in the prominent case of SSL and TLS. Secure Sockets Layer and the protocol which seceded it, Transport Layer Security, works on the application layer (initialized at layer 5 and functions on level 6 of an OSI equivalent framework.) It makes use of x.509 certificates, which in turn, uses the underlying principles of asymmetric key cryptography. A TLS/SSL connection is negotiated with a handshake procedure, in which various shared secrets (i.e. Session Keys etc.) are agreed on. Firstly, a client connects requesting a secure TLS/SSL connection and presents its supported cipher suite comprised of Hash Functions and (Symmetric)Ciphers. The server then selects its prefered Hash Function and Cipher from this list and informs the client. The server will also typically send its certificate to serve as a form of identification. This certificate, in the x.509 format consists of the servers public key, the server name and the CA. (Certification Authority, the security server which issued the certificate.) The client may verify with the certificate issuer for verification before proceeding. The client, upon satisfaction of the server's authenticity, will then generate a random number (asymmetric key cryptography is not immune to random number generation defects) and encrypt it with the server's public key, before sending the ciphertext back to the server. As the server is the only one that possesses the private key, the server should be the only entity able to decrypt the ciphertext and read the random numbers. Using these string of random numbers, a session key or 'shared secret' is generated and used specifically for that session. This session keys is now used as the encryption key for the bulk symmetric encryption algorithm that encrypts the traffic of other protocols eg. FTP(S), HTTP(S). Upon the creation of a new session, this session key is re-generated using the above procedures. As a note of general knowledge, websites secured by SSL/TLS will have an 'S' behind the protocol type, as in the example of HTTP(S), which is used when we log in to Google and Dropbox. The lock icon on Google Chrome beside the address bar also turns green.
(Secure connection to Google's Blogger...yay!)
As we can see from the handshake procedure, SSL/TLS is provides for a more trustable and secured environment to enter our passwords and handle important data. Firstly, any communications towards and from the server are encrypted, ensuring that only entities with the session key (client and server... maybe the NSA) will be able to decrypt the data stream. Secondly, due to the use of digital certificates, we can ensure that we are entering our passwords into the actual website and not a counterfeit set up by phishers trying to purloin your passwords.
As a final note, I would highly recommend people reading this to try out GPG, the freeware PGP equivalent which has been recently taken over by Symantec. GPG provides a very direct interface with asymmetric key cryptography and serves as a great platform for one to try out and experiment with public/private keypairs. It is used to encrypt and sign ones files, emails, corpse of text etc. There might be a bit of a learning curve but given enough grit and determination to overcome the complexities, anyone can use it, even a 14 year old. There is a GUI (Graphical User Interface) named GPA which provides for the familiar point-and-click experience for the Windows User. I might cover more on GPG usage on a future blog post.
---Tristan Voon
Instagram:@armadynecorporation
Cryptographic Data: ceriumsystemscrypto.bravesites.com
Facebook:Tristan Voon
No comments:
Post a Comment