We won't talk about the protocol details, nor about how the published attacks work. You'll find a couple of interesting links at the end though .

Note: Images obtained from the papers linked at the end of the post.

The Crypto1 cipher

Crypto1 is a proprietary stream chiper from NXP found in the RFID tags from the Mifare Classic family. At first, it was studied by Karsten Nohl reverse engineering the chip itself. This information was published in the CCC 07, although not many details about the cipher were published.

In parallel, the Radboud Universiteit from Nijmegen was studying this kind of cards and with the help of the information published at CCC completely reverse engineered the cipher and published the details. Let's see how it works then...

Crypto1 is an LFSR based cipher, which uses just an LFSR with a linear feedback function and a filter function to generate the output stream (keystream):

Crypto1 - Overall structure

The overall structure of the cipher was revealed in the presentation at CCC, but the generating polynomian (the feedback function used by the LFSR) and the filter function was not. The generating polynomial, published by Karsten Nohl et al at Usenix'08, is as follows:

This means that bits 43,39,38...,7,6,5,0 are used to create the new bit that will be shifted into the register. Further, the input bit is used and a XOR of all them is executed to generated the next bit. This polynomial is primitive: irreducible and generates all the possible states before cycling back to the initial state.

On the other hand,the filter functions were published by the people from RU Nijmegen at Esorics'08. The following picture shows those filter functions together with the rest of the cipher.

Crypto1 - Detailed structure

Each of the hexadecimal numbers identifying the filter functions should be read as a bitmap where the left-most bit will be produced as an output of the filter function when the input was all-ones while the right-most bit will be produced as an output when the input was all-zero. For instance, 0x26c7 in binary form would be:

0010 0110 1100 0111

Which means that for inputs (1,1,1,1), (1,1,1,0), (1,1,0,0), (1,0,0,1), (0,1,1,0), (0,1,0,1)  and (0,1,0,0) the result of the filter function would be 0, and 1 otherwise.

Links

This completes the description of the Crypto1 cipher used by Mifare Classic chips. I don't want to get into more details about the structure of the cipher and the protocol, because I didn't look at it in depth amongst other reasons, so for more information you can follow these links:

Reverse-Engineering a Cryptographic RFID Tag - Karsten Nohl et al. Usenix'08

Dismantling MIFARE Classic - Flavio D. Garcia et al. (RU Nijmegen). Esorics'08

Lecture on Mifare Classic from HW and OS Security course at RU Nijmegen

Shift Registers

A shift register is basically a construction with interconnected several memory cells, where every cell stores one bit. So, the value of these cells conforms the so-called state of the register. When the register steps from one state to the next one (usually at each clock tick), the new state is created by simply shifting the bit in a cell to the cell next to it. Thus, the right-most bit goes out of the register, and a new bit goes into the left-most cell.

In this picture we can see an implementation of a 4 bit shift register:

Shift register

We can see an input line (Data in), 4 points where one can read the current state (Q1-Q4) and a clock input, which governs the register telling it in which moment it should step into the next state.

Linear Feedback Shift Registers (LFSRs)

Well, once you know what a shift register is, it is fairly straightforward to understand how a LFSR works. We just take the previous register and set the input as a linear combination of the different cells. Since there is a loop which feeds the register based on its previous state, we have feedback. Further, since this feedback is based on a linear function, then we have linear feedback, hence the name .

LFSR

LFSRs' use in cryptography

So far, you probably have guessed that the main use of an LFSR in encryption systems is generating a series of pseudo-random bits to be used as a key stream in a stream cipher.

The idea is to generate a stream of bits with the minimum repetition possible, i.e. with maximal period. For its study, the connections in an LFSR are usually represented as a polynomial and the properties such a polynomial needs to meet to achieve maximal period are analyzed.

Basically, we need to get the LFSR to run through all its possible states before going back into the first one. So, if we have 16 bit registers, we'd want to have the LFSR pass through the 2^16-1 states before cycling back to the first one. And yes, I said 2^16-1 instead of 2^16 because the zero state should never appear. Otherwise the LFSR will never leave this state, since the feedback function is linear. For the curious readers, an LFSR will have maximal period if its generating polynomial is a so-called primitive polynomial (I'm pretty sure this name will ring a bell for some of you guys, although maybe not as a happy memory ).

Setting aside the study of these polynomials, which involves somewhat comlex maths (to my non-mathematician opinion ), an LFSR by itself should not be used as a key stream generator because its properties make it fairly predictable. In fact, given an n bit LFSR, obtaining 2n bits of its output it is possible to recover the generating polynomial and be able to decrypt any subsequent text.

Therefore, LFSRs are not directly used in crypto, but they are generally used in one of these modes:

• Nonlinear combination of LFSRs: the output from several LFSRs is combined in a non-linear fashion to obtain a key stream.
• Nonlinear filter generator: the output is generated from a non-linear combination of the state.
• Clock-controlled generators: In this mode, several LFSRs step based on some rules, instead of stepping for every clock cycle.

With this kind of constructions it is possible to improve LFSR's properties for the creation of secure stream ciphers. And that's it for LFSRs from my side, for more information refer to these references:

Handbook of Applied Cryptography

LFSR Reference

LFSR @ Wikipedia

Later in this series, we'll see how Linear Feedback Shift Registes (LFSR) work and we'll see one of the most used stream ciphers, together with an example of wrong usage.

Keep on reading to learn more about this class of ciphers.

General features

As opposed to block ciphers, a stream cipher does not divide the plaintext in big blocks where the cipher is applied, but instead it encrypts individual information elements such as bits, bytes or characters.

Generally, based on an initial key a stream cipher derives a series of characters known as the key stream which is then mixed with the input data, or data stream, generally by means of an exclusive or operation.

This is based on the One Time Pad (OTP) concept, which we didn't mention earlier in this blog but most likely you have already heard of it. The OTP is a cryptographic algorithm which simply generates a random key as long as the message to be encrypted and mixes both, by means of a XOR operation in digital communications.

The properties of the OTP algorithm offer absolute confidentiality in the sense that the cryptogram does not reveal any information about the message contents, at the cost of a key as long as the message itself. Obviously, this makes key management not practical at all: where before we had the problem of sending a message of length L in a secure way, now we can send the encrypted message without any fear but still we need to send a key of length L... which leaves us with an equivalent problem!

Following this philosophy of using random keys as long as messages, the stream ciphers that we are analyzing today were invented. To that end, as I explained above, they try to derive a series of pseudo-random characters based on a secret key. This way, one obtains similar properties to the OTP algorithm reducing the complexity of key management... but of course this also reduces the randomness of the key stream.

Stream cipher classification

Stream ciphers are usually divided into two groups: synchronous and self-synchronizing stream ciphers. Most stream ciphers proposed so far are synchronous ciphers, where the keystream is generated independently of the plaintext and the ciphertext. Therefore, these ciphers require both ends of the communication to be sinchronized, and if a single digit of the cryptogram is lost the rest of the plaintext will be unrecoverable (unless error-correcting techniques are used).

Further, in these systems errors are not propagated besides one single character. This allows an active attacker to modify the contents of the ciphertext without detection. For instance, in a system as the one commented at the beginning, where a XOR of the keystream and the data stream is performed, one could just flip a bit in the decrypted plaintext by flipping the same bit in the cyphertext.

On the other hand, self-synchronizing ciphers generate a keystream dependant on the key and part of the previous ciphertext. Therefore, since a given character depends on the previous ciphertext character, if an error occurs it is possible to resynchronize after some time: we just need to discard as many characters as needed so that the keystream doesn't depend anymore on the corrupted ciphertext.

Some security considerations

It is extremely important in a stream cipher that the key stream does not frequently repeat, especially on those ciphers which use an additive function (i.e. XOR) to mix keystream and data stream. The reason is quite simple: if a given message is compromised but the key is not, any message that uses the same key stream could be compromised simply XORing the known keystream and the ciphertext.

Further, in case a message is not compromised but one obtains several messages encrypted with the same key stream, XORing both messages it is possible to remove the influence of the key stream: we would have the XOR of both initial plain texts. This way, we could possibly obtain information on the transmitted messages (structure, statistical properties, ...) that would help us to break the messages.

We could see an example of this method at Campus Party, where Cucaracha decrypted two ciphertexts encrypted using RC4 based on the knowledge that the language was Spanish and guessing the first message and applying the resulting key stream to the second message to see whether the output was sensible or not. It's completely logical, although requires a detailed work and I have to admit that at first I was shocked when he told me that he got the messages but not the key

To avoid this kind of problems, normally an initialization vector (IV) is used to initiate the cipher and have a different keystream each time. Therefore, it is important that the IV is not reused very often.

Last time I wrote about the DES cipher, so today (yes, you guessed it) I'm writing about how the AES works. AES was created as a result of an open contest proposed by the NIST. In 1997, the NIST announced their wish to have a new encryption standard which would substitute the Data Encryption Standard and was to be called AES: Advanced Encryption Standard.

Several researchers submitted their proposals to the AES contest, but the winning candidate was the so called Rijndael cipher. This cipher was originally created by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, who submitted it to the AES selection process.

The other finalists were Twofish (Bruce Schneier and others), Serpent (Ross Anderson and others), MARS (the team included Don Coppersmit) and RC6 (Ron Rivest [the R in RSA :-p ] and others).

After the contest, the NIST published AES as a FIPS standard, and since then the AES cipher has been extensively used and analyzed. In the remaining of this post we see how AES works, as we did with DES in the previous post.

NOTE: Just as in previous entry, images are taken from Wikipedia. Let me know if you try to read the post and they don't work anymore.

AES Structure

Again, we start by looking at the overall structure of the AES cipher. In the case of AES, the block size is 128 bits and the key size can be 128, 192 or 256 bits. The original Rijndael specification also supported several block sizes, but in the AES standard itself only 128 bits blocks are defined.

Just like with DES, the cipher consists of a basic operation called round which is repeated a number of times. In this case, AES is based in a design principle called Substitution-Permutation Networks which means that the cipher is composed of a series of substitutions and permutations one after each other.

The number of rounds (R) in AES depends on the key length: 10 rounds for 128, 12 rounds for 192 and 14 rounds for 256 bits. AES works on a structure known as the AES state, which is simply an arrangement of the block in a 4x4 matrix. Furthermore, most AES operations can be described as operations in the finite field. This gives AES a quite neat algebraic description.

However, they can also seen as byte operations, and we'll look at it mainly as a byte operation, since we don't really want to get into math here (I promised you!). But if you really want to get deep into crypto, then you will certainly need to learn about finite fields. They get more important in public key crypto, where we actually use difficult mathematical problems to protect our data... but we'll get into that later.

The basic building blocks of the AES cipher are as follows:

• SubBytes - A non-linear substitution, the AES S-boxes
• ShiftRows - Shifts the rows of the AES state (hence the name!)
• MixColumn - Mixes columns of the AES state, making each result cell a combination of other cells
• AddRoundKey - Mixes the input AES state with the current round key

As you can see, like in DES we have S-boxes, we have transpositions (ShiftRows), a mixing operation (MixColumn) and an operation to mix the data and the key. An AES encryption consists of the following steps:

1. Initial round:
   • AddRoundKey
2. R-1 rounds:
   • SubBytes
   • ShiftRows
   • MixColumns
   • AddRoundKey
3. Final round (without MixColumns):
   • SubBytes
   • ShiftRows
   • AddRoundKey

So, we have an initial AddRoundKey step, which mixes input data with the 0th round key. Then, R-1 (9,11 or 13) identical rounds take place, and at the end a final round is applied. Now we'll see a more detailed explanation of each of these round components.

SubBytes

As I already said, this is just a substitution table. In this case, we don't have 8 different substitutions as in DES but just one. For those who can understand it, this substitution table is actually an operation on the field with irreducible polynomial which finds the multiplicative inverse of the input byte and then applies an affine transformation.

For those of you who don't know anything about finite fields, let's look at a very basic example of a finite field: the set of integer numbers modulo 7 (i.e., numbers from 0 to 6). With this set of numbers, we can define an addition operation (just add modulo 7) and a product operation (multiply modulo 7), then we would have:

And now, we define the multiplicative inverse of a given member of the field, , as the member such that . So, from our previous example 4 is the multiplicative inverse of 2 modulo 7.

In the case of AES, the operations take place in the field, but the idea is basically the same: we have an addition and a multiplication operation, and we find a number such that after multiplying it by the input number (in the field!) we get 1. I hope it's clear

Now, after taking the inverse (which can be done pretty fast with the extended version of Euclid's algorithm), AES applies an affine transformation to avoid some kind of attacks. An affine transformation is just a construction which takes x as an input, and produces an output of the form a·x+b.

Don't worry, you don't really need to know these details, but it doesn't hurt to have some concept of what AES actually does

ShiftRows

This operation just shifts the rows of the AES state. It's easier to see it with an image:

AES' ShiftRows step

So you can see how row zero remains intact, row one is shifted once to the left (and therefore the first element goes to the last position), row 2 two times and row 3 three times.

MixColumns

This is another mathematical operation which can be seen in several forms. First, it can be seen as a multiplication by a polynomial modulo another polynomial (wow!). Second, it can be seen as a multiplication by an MDS matrix... or you can just think of it as a way of mixing several columns which is easier.

If you want to actually know what happens at this stage, look at the Wikipedia page for the Rijndael mix columns operation.

AddRoundKey

This is the simplest step, but an important one nonetheless... otherwise we wouldn't have any key involved so far! For each round, a round key of the same length as the input block (128 bits) is generated and transformed into the state form. Then, each byte of the current AES state is XORed with the corresponding byte of the key state.

AES Key schedule

So far we've seen all the components of the AES cipher, but we don't know how to generate the round keys. This is done by a scheduling algorithm, which can be run beforehand or together with the cipher. Devices with the luxury of having plenty of memory will normally precompute the round keys, and small devices such as smart cards probably prefer to compute them on the fly because they lack memory space.

The components of the key schedule are:

• Rotate - Rotates a 32 bit word 8 bits to the left
• Rcon - A round dependent constant, which can also be defined as a certain power of two in Rijndael's finite field
• SubBytes - The same SubBytes as in the main cipher

The key schedule algorithm steps are quite large and I do not want to write them down here. You can find them in the standard or in the corresponding wikipedia page: Rijndael key schedule.

AES Decryption

In this case, decryption is not as easy as for DES. Decryption involves performing the inverse operations of the ones performed for encryption, which means that one needs to define the inverse operations for ShiftRows, SubBytes and MixColumns. AddRoundKey does not need an inverse since it is already its own inverse.

Obviously, all these operations are also defined in the standard, and you can take a look at it to know how they are defined.

The algorithm was approved as a FIPS standard in 1976, and revised up to three times in 1988,1993 and 1999. The last revision FIPS-46-3 describes the 3DES extension as a method to enlarge the key size of the DES cipher by using 3 DES operations in a row, encrypting the first time, decrypting the second time, and encrypting again the third time. This was done in order to withstand an efficient brute force attack published in 1998.

After the break (click Read more!) we'll see how it works and the main components of the algorithm.

NOTE: All images in this post are directly linked to Wikipedia. If the images are not visible anymore, let me know in the comments and I'll post my own version of the images.

DES structure

DES is a block cipher which encrypts 64 bits blocks under a 56 bits key. Actually, normally one supplies the DES algorithm with a 64 bits key, but the lowest significant bit of each key byte is not used for the encryption and could be used for parity checking.

The overall structure of DES is depicted in the following figure:

DES structure

It starts by applying the so called Initial Permutation (IP), which obviously performs a permutation, i.e. scrambles the input bits. Then the data block is divided into the upper 32 bits (L0) and the lower 32 bits (Ro) creating a left and a right part. Now 16 identical rounds are applied: a function F (Feistel's function) is applied to the right half and a round key, and the result is XORed with the left half. Then both halves are swapped.

After the 16 rounds have been applied, a Final Permutation (FP) is applied. This permutation is actually the inverse of the Initial Permutation ( ). All these things together conform what we call a Feistel's network, with a great property: we can decrypt the ciphertext with the same algorithm, changing only the order in which we apply the round keys.

This means that the decryption process for DES is identical to the encryption process. Only that round key 16 is applied first, then round key 15, and so on.

The F function

The F function is at the very core of the DES cipher. As explained above, this function is applied in each round to the right half and the round key, and its output is XORed with the left half. At the beginning of the F function, there is an Expansion function (E), which expands the 32 bits input into 48 bits. These 48 bits are then XORed with the 48 bits round key coming from the key scheduling algorithm.

Then, these 48 bits are supplied in groups of 6 bits to the S-boxes. The S-boxes are just substitution functions, which are implemented as a substitution table, and output 4 bits each one. Therefore, the output of the 8 S-boxes is again 32 bits, same size as the input and output of the F function. After the S-boxes, a permutation, P, is applied. The output of the permutation is the result of the F function.

Feistel's function

Key Scheduling

In order to have the complete picture of how DES works, we still need to know how the round keys are computed from the DES key. This is done by the so-called key scheduling algorithm, which can be run in parallel with the DES cipher or precomputed and stored in a table of round keys.

The process looks like this:

DES key schedule

First, a permutation PC1 is performed. The name comes from Permuted Choice, due to the fact that this permutation also choses some bits from the key: the last bit of each byte (i.e, bits 8,16, etc) is discarded as we said earlier, and the rest are used for the permutation.

After this, the structure is repeated for each round key: the result of applying PC1 is divided into left and right halves, these halves are shifted (cyclically) one or two bits to the left depending on the round number. After that, the shifted key is fed to a second permutation, PC2, which selects 48 bits out of the 56 input bits.

Detailed information

So far, we've seen how DES works. However, you wouldn't be able to implement the DES algorithm without knowing exactly how permutations, expansion functions and S-boxes actually modify the data. To that end, you can go to the standard itself or to the DES Supplementary material page on Wikipedia.

As usual, implementing your own crypto is not recommended. Do it only for educational purposes, otherwise things could easily go VERY wrong.

Triple DES

As explained in the introduction of this article, a brute force attack to DES was presented long ago. This attack motivated the introduction of a new variant of DES. This variant, called triple DES, uses three DES operations in a row to enlarge the key space.

Typically the data is DES encrypted with key K1, then decrypted with key K2, and then encrypted again with key K1. This raises the key length to 112 bits (8 bits of K1 and 8 bits of K2 are discarded by PC1), which makes a brute force attack much more difficult.

There exists also a 3DES variant which uses three different keys, achieving a key size of 168 bits. Of course, 3DES can also be used with 3 identical keys. This would give you a DES encryption and allow devices that do not implement 3DES to be used together with devices that implement 3DES.

Block ciphers

As we already said in the previous entry, block ciphers are symmetric ciphers which encrypt fixed length blocks. Therefore, a block cipher generally applies a series of operations combining the input block and the secret key (which isn't necessarily the same length) to obtain the output block (ciphertext).

Since they are symmetric, the decryption primitive uses the same key as the encryption primitive, and applies the operations needed to get back the plaintext at its output:

Most block ciphers can be classified as product ciphers or iterative block ciphers, based on a series of basic operations (rounds) which are repeated a number of times. These rounds provide confusion and difusion to the cipher, two concepts identified by Shannon in his famous treaty about communication theory.

Confusion refers to breaking the relationship between ciphertext and key as much as possible, while diffusion refers to destroying the statistical characteristics of the message source. Shannon identified these concepts and established the need for a secure cipher to provide them.

These kind of ciphers are generally Substitution-Permutation Networks (SPN), where several permutations (scrambling) and substitutions (changing values for others) take place one after the other, using a key, trying to achieve the goal: destroy the statistical properties of the source and obtain a secure cipher.

In subsequent entries we'll see how DES and AES, two well-known symmetric encryption standards, work. The remaining of this article treats block cipher modes of operation and how to authenticate messages using these ciphers.

Modes of operation

We'll see now some constructions that allow the use of a block cipher to encrypt texts larger than the block length. Some of them can be viewed as stream ciphers in which a key stream is generated and gets mixed with the plaintext.

First, we'll see the most simple way of using a block cipher. The construction that would come to every mind would be dividing the plaintext in blocks of the suitable length and encrypt each of them. This is what we call Electronic Codebook Mode (ECB), and as can easily be observed, it mantains the structure of the plaintext at the block level (not inside blocks): two identical blocks produce the same ciphertext under the same key.

After ECB, one of the most famous modes is the Cipher Block Chaining (CBC). In this case, the plaintext is also divided into several blocks, but before encrypting them with the secret key, they are XORed with the previous ciphertext block:

Where would be the so called Intialization Vector (IV), which can be different each time but doesn't need to be secret. Actually, it's usually known, either being a fixed value defined in the concrete protocol's specifications or sent together with the message as a header.

In this way, each encrypted block depends on each one of the previous blocks. A simple bit change in one of the blocks would produce a cascade effect and make the remaining blocks completely different. Clearly, message structure at the block level is not revealed. This is well illustrated in the following image from Wikipedia:

TuX encrypted using ECB

TuX encrypted using a secure cipher

But not only CBC exists. For instance, the Output Feedback Mode (OFB) generates a bit stream to be used as a key, in the most pure stream cipher style. The cipher is initialized with an IV in the same way as CBC, but it is encrypted using the secret key. The resulting block has the k initial bits of key stream, which are XORed with the plaintext to produce the ciphertext.

To generate the next keystream bits, the previous block is used. Using the usual notation:

Obviously, decryption will be performed calculating the same keystream and XORing it with the ciphertext. This construction creates a stream cipher, and as other stream ciphers, if one bit is flipped in the plaintext, it will also be flipped in the ciphertext (and the other way around) due to the usage of XOR.

Another quite common mode is the counter mode (CTR), in which a counter is used at the input of the block cipher, and the output is used in the same mode as in OFB mode.

These are not all the existing modes, but the intention is simply to provide an overview of the options and to refer the interested reader to other sources. See for instance the famous Applied Cryptography from Bruce Schneier, or the Handbook of Applied Cryptography.

Message Authentication Codes

One of the problems that Cryptography's tried to solve, is the authentication of the data origin. This is, trying to assure that a message has been actually created by a certain person, machine or, more in general, entity. The solution to this problem based using symmetric crypto is known as Message Authentication Codes, or MACs.

These codes are just a block of groups generated by some alrogithm using a secret key and a plaintext message. The most common construction for generating these codes is based on using a block cipher in CBC mode, but taking just the last block as the MAC.

As we've seen previously, this last block depends on all the previous blocks, as well as on the key. Therefore, this code is binded to the complete message (provides message integrity) as well as to the entity with whom the secret key is shared (provides data origin authentication).

Thus, the receiver of the message, who shares a secret key with the source, is able to check whether the message was actually generated by the expected entity and that it has not been altered.

In this post we'll see some of the options provided by Cryptool to analyze classical ciphers, as well as using it for breaking a ciphertext encrypted with Vigenère's cryptosystem.

First step, as usual, consists of installing Cryptool. To that end, I chose using a virtual machine in VMWare with Windows XP. The installation is very simple, typical Windows app installation: Next, Next,... We'll use the English version, which is the one I have installed, but it shouldn't be difficult to follow our steps with a different version.

Once installed, this is how the main window of Cryptool looks like:

Cryptool's main window

Looking at the menus, one can see that Cryptool offers (amongst others) the possibility to encrypt and decrypt texts, cryptanalytic tools and guided tutorials. In this text we'll see how to use Cryptool for analyzing encrypted texts... Let's start with an easy one:

Gznyrém xlmlxrwz xlnl Fmrevihrwzw Klorgéxmrxz wv Ezovmxrz, l vo
Klor kziz olh znrtlh, vh fm lhxfil oftzi oovml wv vhgfwrl b kvievihróm.
Hlyivglwl, klijfv glwl zjféo ol hfurxrvmgvnvmgv olxl xlnl kziz vmgizi
vm vooz, gvmwiá jfv szxvi zotl wv ol zmgvirlinvmgv xrgzwl kziz hzori
zrilhl wv vooz. Vmgiv olh oftzivh náh xlmxfiirwlh, hv vmxfvmgizm oz
Xzhz wvo Zofnml (szyrgfzonvmgv fhzwz kziz wlinri olh qfvevh wv
nzwiftzwz, kvil gznyrém kziz qftzi z yroozi l ufgyloím, zfmjfv mlh
jfrgzm vhgv vm éklxz wv vcánvmvh), oz Yryorlgvxz (wlmwv oz tvmgv hv
wrervigv vhgfwrzmwl), b ozh krhgzh wv gvmrh b káwvo.

The text has been obtained from IEEE's cryptography challenge, by Javi Moreno and Amine Tourisa (sorry, Spanish). Actually, the solution was already published in Javi's blog, but we're gonna see how to obtain it with Cryptool:

• Create a new document ( File | New )
• Copy the text from the challenge
• Go to Analysis | Tools for Analysis | Histogram

Now we get the following frequency diagram from the text:

Frequency analysis of the ciphertext

Next we just compare this diagram with the typical one from Spanish or English, and we can see that it's simply been 'mirrored'... easy, isn't it? So the answer is, as you probably guessed, ATBASH. Decrypting the text with ATBASH (Crypt/Decrypt | Symmetric (Classic) | Substitution/Atbash ... ) , we get this cleartext (again, Spanish):

También conocida como Universidad Politécnica de Valencia, o el Poli para los amigos, es un oscuro lugar lleno de estudio y perversión. Sobretodo, porque todo aquél lo suficientemente loco como para entrar en ella, tendrá que hacer algo de lo anteriormente citado para salir airoso de ella. Entre los lugares más concurridos, se encuentran la Casa del Alumno (habitualmente usada para dormir los jueves de madrugada, pero también para jugar a billar o futbolín, aunque nos quitan este en época de exámenes), la Biblioteca (donde la gente se divierte estudiando), y las pistas de tenis y pádel.

Now we'll see how to solve a Vigenère encrypted text. Let's take as our working example the following text:

Yyi plqqsjiw icd rfwx vcrynevh ozi fxlhf bwrgxlqmq nsvng mwv hivwssvh
xr hmpv eadm ktlv jusqifq xr gtfii eqr omrrkh htj nsvng.  Nd tsrwfmxk,
xlh UZZ Xirhfmq Gyfowo Qzgiqgq nj mrwszivh xr ugfierwsq dfyv ifqjusq wc
emrvi dbp hyerjs mqc ziugutew si o bwfkvda--ft deoh ggwv mx usyfzrw ifqj
jsjwkmwv jsu oxq zxw xgqwj.  Ai, wvq Kiii Vcrynevh Tazehewwas, lwi wvq
LEY Khbqwrp Txpxnt Pmfszxv jsu aaxk sj rid xfjxzodj; zx esdxnvw eoga yf
erb cfmvv arfw wvpidgqi klmv kmd sc mwg mzklsug.  Ktl geq obucc mw ha
dfyv sfalieqv, hat.

Nliq kq xgien cr kiii vcrynevh, kq fii vhtqwimrj ha kiiigcy, sfx
tuwoj.  Fyv Jszjiep Sinqzg Plqqsjiw dfq ivwmjbqi ks qdyq xlvi wvmy psy
kohj kli ifqjusq wc pnjxvlpgyv gsswqx fj jusq xfjxzodj (rrh fvmwxi jrf
fmvq mi maz nmwk), htfk csx fqhvmzh gazigi fcpj fv gdb sjk mx lt ktl
aeqh uy, klew maz ter fvmsxi xks etwxadfq ti ywh dujtiw rt uy zr rhk
rwvi tucswrqw, dbp yyex bcg pesa bcg hrr hr htjji xkwzlj.

Xs sfayvgx bcgw imkkhe, bv rihr ft gviyszy fxlhfe kisq gszdzrk bcg
yyiwh fulyxw rf mxbmrj maz ks wxfdjehiu htj imkkhe.  Yyivhtawv, csx vmav
giuhmne vivdasjmflzuyziw lt ktl hmvhdnsyxh qauziw rt fmv wsihifii, su wr
dfy qrrukp mx: useufrwlpuqzxmhg ft iiwssoy kli ifqjusq rt ayyivv.

Again, we create a new document in Cryptool and paste the text in. Now we go to Analyze | Symmetric Encryption (Classic) | Ciphertext-Ony | Vigenere.

After doing so, Cryptool will suggest a key length, and when we accept, it will tell us the key and allow us to decrypt the complete text, this time in English. We can also choose to see every step, with the Show base ciphers analysis option in Options | Analysis Options.

Further, Cryptool's output offers a plot with the text's autocorrelation, with periodic peaks in multiples of the key length This is the tool used by Cryptool to analyze Vigenère's cryptograms, and we can also find it directly available in Analyze | Manual | Autocorrelation. This tool can be used to analyze texts and decide whether it could be a Vigenère (or similar) cipher or not.

That's it for today, I recommend you to keep on playing with Cryptool and to take a look at its official documentation.

The Enigma Machine

The Enigma machine was developoed and patented by Arthur Scherbius in 1918, and was adopted by the nazi Germany for military and diplomacy use. Polish cryptanalysts broke the Enigma cipher in the late 1930s, and Allieds exploited this knowledge during WWII.

Máquina Enigma

It is said that thanks to Enigma being broken without the Germans noticing it (thanks to the more or less careful use of the obtained intelligence) the WWII was shortend one year or even more. There has been a lot of writing around Enigma, and I'm not an expert in the field, so I refer you to Google if you want more historical information

Encrypting and decrypting with Enigma

To encrypt with Enigma, after initializing the machine with the key as we'll see later, one simply had to press the plaintext letter to encrypt in the keyboard, and then the corresponding ciphertext letter would be enlightened in the upper (back-lighted) keyboard.

To decrypt, one had to set the machine into the corresponding state and press the received ciphertext letter. Then, in the upper keyboard the plaintext letter would get enlightened.

Enigma's features

Enigma was an electro-mechanical machine, based on the use of rotors. In the previous figure, one can easily see the mechanical keyboard and the back-lighted keyboard, which worked as input and output of the device.

Further, there is what seems to be a switchboard (stekker in German) with cables connecting one of the ends with another, and three rotors in the upper side of the machine. The configuration of these rotors and the cables of the stekker are the initial key of the machine.

Once the machine was initialized, it was possible to press in the keyboard the plaintext or ciphertext letters and obtain the ciphertext or the plaintext respectively. The workings of the machine were essantially as follows:

After pressing a key in the keyboard, a signal was sent through the corresponding stekker pin. Thanks to the cable configuration, this signal was transmitted to a different letter. Thus, the stekker worked as a mapping in the alphabet, where each letter was substituted by another one: a simple substitution.

Rotores de la máquina Enigma

After it, the signal went through the three rotors, reflected in the reflector and went back through the rotors (see figure). Finally, from the rotors it went again through the stekker, which performed a new substitution, and turned on the backlight of the corresponding letter. The net effect of the rotors and the reflector was again a permutation: each letter was converted into a different one.

However, if this were it, we would have no more than a simple substitution, with the only complexity of the use of an electromechanical machine. What Enigma added was a variation of the disposition of these rotors.

Each time a key was pressed, the rightmost rotor stepped one position. The middle rotor stepped in an odometer-like fashion, each time the rightmost rotor went through all of its steps. The leftmost rotor stepped in the same way, but depending on the middle rotor.

Further, it was possible to select the point where each rotor would step. This means that it could be when the previous rotor reached the initial position, but it could be in a different position. We could set it, for instance, to step when the previous rotor had stepped 5 times. From there on, it would step every time the initial rotor was in that position.

Therefore, Enigma was a cipher where each letter was encrypted with a different simple permutation of the alphabet... but with an enormous number of possible permutations.

For a more detailed analysis of the Enigma machine, please refer to the aforementioned book, where the way the machin works is analysed, the key space size (i.e. number of possible keys) is computed and an attack is presented.

Friedman's test or the incidence of coincidences

This method, discovered by William F. Friedman in the 1920s, is based on computing the index of coincidences of the cryptogram's letters. The idea is that for two random letters from the cryptogram to be the same, there is a possibility that they were also the same in the original plaintext if the number of letters they have in between is a multiple of the key length.

Basically, we'll take the X first letters of the cryptogram and the X last letters, and count the number of coinciding letters in the same position. Finally, we'll divide this number by the number of letters taken and then we will have the index of coincidence.

Considering a source providing independent characters with the frequency distribution of English, and uniformly distributed characters for the key (i.e. all letters with the same frequency, 1/26 for the English alphabet), we have that:

• The probability that any two letters are the same is approximately 0.0385 when X is not a multiple of the key length
• The probability that any two letters are the same is approximately 0.0688 when X is a multiple of the key length.

So, with this process wi can determine that high values for the index of coincidence will mean that the shifted distance X is a multiple of the key length, and this way we will determine the most likely key length.

Let's see how we get these probabilities, so that we are able to obtain them in case of having a language different than English. We simply have to consider that for any two ciphertext characters and to coincide, the following relation must hold:

Then, we consider two different cases: if L divides i-j, then , since in that case we have that  . So, the probability for this case is:

However, when i-j is not a multiple of L, then for the two ciphertext characters to be equal the following equation needs to hold

But as we said before, the distribution of key characters is uniform, and therefore this probability is:

That's it for today. This time there is no example, but stay tuned cause we'll see an exercise soon

And I hope next week I'm able to post some practical exercise using Cryptool to analyze a Vigenère cipher or something alike.

This post will study one of the most known classical ciphers, the Caesar cipher, and other similar ciphers.

Caesar Cipher

Caesar's cipher, named after Julius Caesar, is a substitution cipher that simply substitutes each letter by the letter K positions to the right in the alphabet. So, for a K value of 3, A would be encrypted as D, B as E, C as F and so on.

In mathematical terms, considering an alphabet with 26 letters, where A would be letter 0 and Z letter 25, we can define these encryption and decryption operations as:

Where means reducing the result modulo 26, or in simpler terms, if the result is above or below the 0-25 range, we would add/subtract 26 as many times as needed to make it fall into this range.

As you can see, very simple. For instance, if we encrypt the sentence CRIPTOGRAFIA PARA TODOS under key 5, we get the following ciphertext: HWNUYTLWFKNF UFWF YTITX.

Here we can already see one of the weaknesses of this cipher: the structure of the plaintext remains. As you can see, last word in the message starts with a Y, then it has two T's, one I and one X. Therefore, we know that this word has the second and fourth letter identical. Also second and fourth letters are identical in the second word, but different to the ones in the last word.

This, in a large text and within a context, could lead us to decipher great part of the text. For instance, knowing that it's a text about information security, we can try to find words with the same structure as security or information and map these letters for all the text. With this, we would have parts of other words, and with some luck we would be able to obtain more letters by guessing those words. Continuing like this, at the end we would have the complete text.

Another tool that allows us to easily analyse this kind of ciphers is frequency analysis, which we mentioned previously. If we take a text encrypted using this system and count the number of appearances of each letter, and then obtain (or generate) a table of relative frequencies for the target language, we can match the most frequent letter in the ciphertext and the most frequent letter in the target language.

Then, since the same shift is applied to all the letters, we would have the key and would be able to obtain the complete message. In case of getting a non-sense message, we could try with the second most frequent letter instead of the first one. Since it's a statistical analysis, it's possible that the character distribution in our text doesn't completely match the original distribution, but will certainly be similar.

Simple substitution ciphers

Caesar's cipher we just analysed is one of the so-called simple substitution ciphers, which always substitute each symbol of the input alphabet by a given symbol of the output alphabet.Besides Caesar's cipher, Atbash cipher is another quite famous substitution cipher, where each the alphabet is inverted: A->Z, B->Y, ... Y->B, Z->A.

But not only these two simple substitution ciphers exist. We can create any modification of the input alphabet as output alphabet. Even then, all these ciphers suffer from the same problem: the structure is maintained and they are quite easy to break using frequency analysis and word matching.

Example: Breaking a simple substitution cipher

This time I encrypted an English text. This is how the ciphertext looks like:

ZL VAGRERFGF NOBHG FRPHEVGL ERYNGRQ GBCVPF UNIR QEVSGRQ N YVGGYR OVG, ZBIVAT SEBZ CHER FBSGJNER NAQ ARGJBEXVAT FRPHEVGL GB PELCGBTENCUL NAQ CENPGVPNY NGGNPXF BA PELCGBTENCUVP VZCYRZRAGNGVBAF, YVXR FVQR PUNAARY NANYLFVF NGGNPXF.

VA GUVF EROBEA OYBT V JVYY GEL GB VAGEBQHPR GUR ERNQREF VAGB GURFR GBCVPF JVGUBHG TRGGVAT VAGB GBB PBZCYRK ZNGUF. GUR NVZ VF GB CEBIVQR NA HAQREFGNAQVAT BS PELCGBTENCUL JVGUBHG UNIVAT ERNQREF YBFG BA ZNGURZNGVPNY PBAPRCGF. LBH JVYY GRYY JURGURE V NPUVRIR GUVF TBNY BE ABG.

Looks pretty complicated, doesn't it? Let's see how to approach this example, assuming this is a simple substitution cipher. First of all, we're gonna count how many times appears each letter, and then divide it by the total number of letters. I've done it with this simple program I quickly coded, although it's possible to do it with Cryptool but I don't have it available right now.

Once it's done, we sort it by frequency. For instance, copy-pasting the output of the program into a spreadsheet in Google Docs and pressing order by the corresponding column. The top 3 letters are:

G     52    0.124402

R     38    0.090909

V     37    0.088517

So, we go to a frequency table for English (here) and see that E is the most frequent letter in this language. Now we subtract 'G'-'E'=7. If we apply this key using a Caesar's cipher, we just get garbage. However, if we take 'R' as 'E, then 'R'-'E'=13. Deciphering using Caesar's cipher, we get:

MY INTERESTS ABOUT SECURITY RELATED TOPICS HAVE DRIFTED A LITTLE BIT, MOVING FROM PURE SOFTWARE AND NETWORKING SECURITY TO CRYPTOGRAPHY AND PRACTICAL ATTACKS ON CRYPTOGRAPHIC IMPLEMENTATIONS, LIKE SIDE CHANNEL ANALYSIS ATTACKS.

IN THIS REBORN BLOG I WILL TRY TO INTRODUCE THE READERS INTO THESE TOPICS WITHOUT GETTING INTO TOO COMPLEX MATHS. THE AIM IS TO PROVIDE AN UNDERSTANDING OF CRYPTOGRAPHY WITHOUT HAVING READERS LOST ON MATHEMATICAL CONCEPTS. YOU WILL TELL WHETHER I ACHIEVE THIS GOAL OR NOT.

Much more readable Don't you recognize it? Look at http://www.limited-entropy.com/en/about

We've decrypted the text, although not at our first try, but at our second. Another option would have been using 'G' as 'T', since T is the second most frequent letter in English. The result is exactly the same.

However, facing an unknown transformation, we would have been to play with other hints besides frequency analysis. For instance, we could use the fact that we expected to see CRYPTOGRAPHY in the text, and assign this word to the only word in the ciphertext that has the same letter in the third and the last position. Then, we would substitute all its letters in the ciphertext and would see if it makes any sense.

From there, we just need to continue on guessing letters... kind of a puzzle

That's it for today, I hope you're liking it . Questions and comments are more than welcome!

• Ciphertext-only: The cryptanalyst knows only the ciphertext, and often also some information about the context of the message.
• Known-Plaintext: The cryptanalyst knows pairs of plaintexts and corresponding ciphertexts.
• Chosen-Plaintext: The cryptanalyst is able to choose plain texts and obtain their corresponding ciphertexts.
• Chosen-Ciphertext: The cryptanalyst can choose any ciphertext and obtain its corresponding plaintext.

Although the final two kinds could seem to be identical, there is a big difference mainly when applied to public key algorithms. In these algorithms, it is usually very easy to encrypt any plaintext. Thus, these algorithms need to withstand chosen-plaintext attacks. However, a chosen-ciphertext attack would require a decryption oracle, which would return any ciphertext decrypted without exposing the decryption key.

Cryptography is the science studying information protection, both unauthorized accesses/uses and modification of the information. Cryptography is only about using algorithms to protect this information, while Cryptanalysis is about studying techniques to break this protection, those algorithms designed by cryptographers. It's clear that both sides are intimately related, and both of them are grouped in what is known as Cryptology.

A Cryptosystem is made of the following components:

• Messages: The group of all the messages that one can encrypt. Also known as plaintext.
• Ciphertexts: The group of all encrypted messages.
• Keys: The group of all the secrets that can be used to obtain a ciphertext from a plaintext.
• Encryption and Decryption algorithms: The algorithms or transformations that need to be applied to a plaintext in order to convert it into a ciphertext or back, using a secret key.

Un Criptosistema o Sistema Criptográfico consta de los siguientes componentes:

• Mensajes: Es el conjunto de todos los mensajes que se pueden cifrar. El llamado texto en claro o plaintext.
• Criptogramas: El conjunto de todos los mensajes cifrados. En inglés llamado ciphertext.
• Claves: El conjunto de secretos que se pueden utilizar para obtener un criptograma en base a un mensaje.
• Algoritmos de cifrado y descifrado: Los algoritmos o transformaciones necesarias para convertir un mensaje en su correspondiente criptograma y viceversa, haciendo uso de una clave secreta.

So, given a cryptosystem with its encryption algorithm, which we denote as , and its corresponding decryption algorithm ( ), the following equation must hold:

Where k y k' are the corresponding encryption and decryption keys. These keys might be identical (symmetric crypto) or different (asymmetric crypto), as we'll see later.

This means that when you decrypt a message encrypted under key K using its corresponding decryption key K', you obtain the original message. Obvious, isn't it?

The figure below shows the conventional cryptosystem as depicted by C.E. Shannon in its book Communication Theory and Secrecy Systems.

Cryptosystem scheme

Finally, to finish this post about basic concepts, we'll see how to statistically characterize a message source. Statistical characterization of a language is a quite powerful tool on its own when it's about analyzing a cipher, specially in case of basic ciphers as we'll see in the next post.

Let's imagine a message source that produces messages in a given language, for instance Spanish. We can try to characterize the source by  means of the probability that a certain character appears in the text, independent of the rest of the text.

Thus, a character c would appear with a probability . With this characterization, the word hola would appear with a probability of:

A slightly more powerful option would be characterizing the language as a series of bi-grams (i.e. groups of two characters) with a given probability. In this case, the word hello would have the following probability:

However, this option besides being an identical concept to the former one, requires of much bigger frequency tables and more effort to characterize the message source.

A question that might arise now is how would we manage to  obtain a table of relative frequencies for each one of the letters. Basically, we would take a sufficiently large text in the given language and count the number of times each letter appears. Then we divide this number by the total of letters in the text, and get its relative frequency. Frequency tables can be seen in Frequency Analysis [Wikipedia].

Next time we'll see how this frequency characterization with independent charactes can be useful to break basic ciphers.

At the beginning of last month I ordered a copy of The IDA Pro book from Chris Eagle at Amazon. Since reversing has been one of my pending subjects for a while now, and after seeing it recommended by Ilfak's himself, I decided to buy the book. I've just finished my first reading of the whole book, and before going into applying the acquired knowledge I've thought it may be useful to share my opinion with you.

The book is divided into 5 different parts. Part I, Introduction to IDA, covers the very basis about disassembling, reversing and reversing tools, and IDA Pro.

Part II, Basic IDA usage, introduces the reader into the IDA world in chapters 4 to 10. After introducing the user interface and the different IDA displays, Chir Eagle goes into disassembly navigation and manipulation, data types, cross-references and graphing, and finally the different IDA flavours apart from the normal Win32 GUI version (console mode for Windows,Linux,OS X). Chapter 8 about datatypes and data structures also provides a nice covering of C++ reversing, showing how to locate vtables and explaining inheritance relationships among others.

Part III, Advanced IDA usage, extends the IDA knowledge provided in the previous part by discussing its configuration files, library recognition methods, how to extend IDA's knowledge about library functions and, although it is not its main purpose, what can IDA do for us if we want to patch a binary.

Part IV of the book discusses the available options to extend IDA's functionality: IDC scripts, the IDA SDK, plug-in development and processor and loader modules. To be honest, I skipped a big chunk of this part because I believe it is not worth now. I'll just come back to these chapters once I start disassembling things and needing to tailor IDA's functionality to my needs.

Part V discusses how to deal with real-world problems. It starts with a chapter about the different assembly code produced by different compilers for the same source code, and then goes into a very interesting description about obfuscated code analysis (from the static analysis perspective mainly). Next, Eagle gives some hints on how to use IDA for finding vulnerabilities and provides a list of several useful real-world IDA plugins.

Last part of the book, Part VI, discusses the IDA debugger and its integration with the disassembler. This part starts with an introduction chapter, continues with a discussion on its integration with the disassembler and ends with a chapter about remote debugging with IDA.

As you have seen, this book provides a thorough coverage of IDA's capabilities, and gives real world examples. The examples, together with the IDC and plug-in code, make it a very interesting reading for those willing to learn about reversing and about the most popular disassembler these days.

If you'd like to learn how to use IDA efficiently, how to tailor it to your needs and automate your static analysis tasks, this is your book. Definitely, it is worth the money if you want to get into IDA and have a good reference book.

- Primero: La gloria, la fama, el honor de hacer un solucionario y responder a una entrevista para el lado del mal. Además, una cena y unos cubatas en tu ciudad (como gane quién yo me sé va a ir a Zurich la madre del topo) que quedará para la historia con fotos que no querras-que-vean-tus-descencientes.

UPDATE: El primero se llevará el Badge de la Defcon16

- Segundo: El honor de ser el primer Luser, el gran perdedor, el perdedor oficial. El título honorífico de ser el Luser del Reto Hacking IX y sí, una cena, pero las copas las pagas tú que para eso deberías haber ganado.

UPDATE: El segundo se llevará tres pegatas de la Defcon16

- Tercero: A ti te voy a regalar un libro de hacking para que sigas practicando y así alcances la gloria de ser el campeón o de ser el No Luser.

UPDATE: El tercero se llevará una pegata de la Defcon16

Yo si tengo tiempo me pondré a ratos, aunque en un plazo de una semana presento el PFC y luego vienen fiestas del pueblo, así que no estaré muy libre para ponerme...

Suerte a los que os decidáis!

EDITADO: Ayer estuve pegandole un ratillo cuando llegué a las 9, un poquitín más después de cenar y otro rato cuando volví de dar una vuelta por ahí. La cosa va de romper CAPTCHA's, pasé los niveles 1-5 pero el 6 se me resiste... no veo NADA de momento .

Las soluciones las estoy haciendo con PHP con libcURL, reutilizando un script que usé en la CampusParty de 2006 (creo). Te suena Javi? xD Esta vez toca hacer cosas 'parecidas' pero hay que saltarse el captcha 1000 veces en 60 minutos, con lo que automatizarlo es clave (y un coñazo la espera xD).

EDITADO 2: Pues ya hay ganador. Kachakil acaba de alzarse con la victoria y con los 10 puntos... el tío está en el top en todos los retos. Enhorabuena desde aquí!

Prueba 1: token01

En esta prueba había que obtener un token para acceder a la próxima prueba, mediante una aplicación que te ofrecía un desafío y había que responder con la respuesta correcta. O bien hacer un poco de ingeniería inversa, claro. En este caso era fácil, solo con strings podías sacar el token, pues salía esto:

cuchara@vm02 /home/pruebas/cuchara $ strings token01
/lib/ld-linux.so.2
libcrypt.so.1
__gmon_start__
_Jv_RegisterClasses
crypt
libc.so.6
_IO_stdin_used
exit
strncmp
puts
printf
strlen
__errno_location
read
open
scanf
__libc_start_main
GLIBC_2.0
PTRh0
0[^]
[^_]
Enhorabuena, has pasado la autenticacion. El token es: dyP6IQCjo05S51x

Prueba 2: Aplicación web

En este caso, nos daban la URL de un servicio de webmail, y nos pedían obtener un archivo en el directorio padre. Mirando el código fuente HTML se veía un comentario indicando que se trataba de Endymion MailMan, y buscando en bugtraq encontramos esto.

Como pone, usando la variable ALTERNATE_TEMPLATE podemos conseguir un file disclosure, y allá que fuimos. Agregando esto a la URL: ?ALTERNATE_TEMPLATES=../u1Bjnk0R18maywv%0 0 conseguimos leer el archivo u1Bjnk0R18maywv situado en el directorio padre al servicio de webmail.

Prueba 3: token02

Otra de tokens, con un binario de por medio. En este caso, strings no daba ningún resultado así que no me calenté mucho la cabeza. Como gdb estaba disponible, cogí y puse un breakpoint justo tras la comprobación de la respuesta. Al ver que eax estaba a cero y se usaba para comprobar si el desafío era correcto (era el resultado de una comprobación) lo puse a 1 y arreglado:

(gdb) set $eax=1
(gdb) next
Single stepping until exit from function main,
which has no line number information.
Enhorabuena, has pasado la autenticacion. El token es: a15EJwU8wjkX

Sencillito Aunque quizás lo suyo habría sido copiar el binario y parchearlo... pero no había ganas, gdb es más eficiente para estos casos jeje

Prueba 4: Escalada de privilegios

Esta prueba no era difícil pero se nos (me) atragantó. Y me cabreé bastante conmigo mismo por no verlo, todo hay que decirlo . Nos daban un ejecutable con bit setgid activo, para leer un archivo mediante el uso de una contraseña.

Tras probar los típicos parámetros larguísimos de N-mil A's y ver que no petaba, pasé al desensamblado y a leer el código. El programa usaba strncpy para copiar el password a una variable local (llamémosla buf), llamaba a check_pass(buf). Seguidamente sumaba el valor devuelto por check_pass a una variable local que había inicializado a 0 al principio del programa, y si el valor era 0xeb llamaba a read_file(argv[2]).

El problema aquí fue que estuve eones intentando entender check_pass, tratando de hacer gdb saltar a la función read_file como hice en token02, pero claro, daba error de archivos pues al estar usando gdb no se ejecutaba con los privilegios del setgid.

Al final, tras las 3 horas lo dejamos y lo recogí al día siguiente por la mañana. En 5 minutos me di cuenta de que el strncpy() copiaba 100 bytes y sobreescribía la variable local (solo un byte) que se sumaba al resultado de check_pass, que era 1 cuando el password era incorrecto.

Así pues, la cosa quedaba algo así:

plato@vm02 /home/pruebas/plato $ ./leer_archivos `pe rl -e 'print "\xea"x1000'` secreto
Enhorabuena, has conseguido leer el archivo secreto.

El codigo de validacion para pasar la prueba es: cfn3HqqbJlSeHsP

Que lo disfrutes

Sencillo verdad? Pues no lo veía, hay que... jejeje Nada como una noche descansando y una buena ducha para olvidarse de todo lo que ya has probado y ver estas cosas.

Prueba 5: Password Cracking

Seguidamente nos pusimos con una prueba de password cracking. Nos daban un / etc / passwd y había que crackearlo en 4 horas.

Esta fue la prueba que menos me gustó. Había que aplicar un ataque por diccionario, pero si no tenías el diccionario en concreto lo tenías mal porque el password no tenía ningún sentido... usamos más de 4 horas y perdimos el bonus, pero bueno... que se le va a hacer, no nos iban a gustar todas las pruebas.

El hecho de que no me gustara es más bien porque influía mucho más la suerte de tener el diccionario concreto que las habilidades del participante.

Prueba 6: Wifi

Esta era fácil. No me pareció demasiado justo que valiera 1600 puntos pero bueno, así son las cosas. Se trataba de una captura de 2 paquetes de una wifi de las de telefónica/imagenio. Sí, de estas de WLAN_XX en las que la WEP solo depende de la MAC, la marca del router y alguna cosa más... y al final solo tienes unas 16^4 posibilidades (si no me falla la memoria).

Total, que usas wlandecrypter o algo similar tras generarte el diccionario y arreglado.

Prueba 7: token03

Otra de los tokens, esta vez un poquito más difícil. Había que obtener la respuesta para un desafío concreto. Lo que hicimos fue cargar el binario en gdb, y analizarlo un poco. Se veía que se leía de /dev/urandom, había un printf que probablemente mostraba el desafío, y un scanf que leía el mismo.

Tras ello había un crypt() y un strncmp(). Esto nos indica que probablemente la respuesta al desafío fuera crypt(desafio,salt), donde nos falta por averiguar el salt. Con gdb o con IDA Pro era fácil encontrar el salt, que era la cadena cp.

Así pues, este sencillo programa nos daría la solución:

#include <stdio.h>
#include <unistd.h>

int main(int ac, char **av){
char *str;

str=crypt(av[1],"cp");

printf("%s\n",str);
}

Tras ejecutarlo como:

$ ./a.out HugGOJ28
cpbSFUhk1FzG

No era demasiado difícil no?

Prueba 8: Ingeniería inversa

Esta era la última prueba (si no me dejo ninguna). Esta no la pasamos, porque era muy complicada y porque no teníamos nada de tiempo. Se nos daba un dump de memoria (a partir de la dirección 0x080000) de un integrado, del cual se nos daba la foto. Aparecía marcado GC2-D2C en el mismo, lo que nos indica que algo tiene que ver con la wii.

Ahora sé que es un micro Panasonic MN102 y parece estar soportado por IDA Pro, al menos la versión 5.3 debería soportarlo. Se nos pedía un password que controlaba el acceso al resto del firmware y la función de la instrucción 0x60.

No llegamos a analizar nada, puesto que quedaban 2 horas y dieron 8 para el bonus, así que nos dio tiempo a nada. A parte de que no sabíamos qué micro llevaba ese chip y no podíamos desensamblar nada claro...

En fin, esta me la dejo por si tengo un rato y ganas de frikear... si lo hago ya contaré algo por aquí

Se acabó

Pues eso, hasta aquí mis soluciones rápidas a las pruebas del concurso de seguridad de esta Campus Party 2008. Desde aquí agradecer a Pedro, Rapul y Jaime por el curro que se pegaron con el concurso, y por entretenernos un tiempo.

Y también dar las gracias a Javi y a Amin por ese equipo que formamos, que funcionó a la perfección Y también quiero cagarme en el mod_security de este servidor... que no me dejaba postear algunas palabras, de ahí los espacios que he metido en algunos.

• Introducción
• Modelado (I)
• Modelado (II)

Ahora nos toca ver cómo completamos nuestros modelos mediante la inclusión de los objetivos del protocolo en ellos. En spi-calculus, para modelar el objetivo de confidencialidad simplemente usamos aserciones ( secrecy assertions en inglés ). Las aserciones son mecanismos que no modifican el flujo del modelo ( no influyen en la semántica operacional ) y simplemente indican que un agente espera que un determinado valor se mantenga secreto. Por ejemplo, podríamos escribir:

Pa = new s; ( secret(s) | out net {s}kab)
Pb= inp net x; decrypt x is {s}kab; secret(s)

De esta forma, se especifica que ambos agentes creen que s es un secreto.

Por otra parte, para especificar opciones de autenticidad nos valemos de aserciones de correspondencia ( correspondence assertions ). Esto simplemente significa que el agente que inicia la autenticación iniciará la aserción de correspondencia con unos parámetros, y el que la acaba la finalizará. Para que todo vaya bien, si existe una finalización debería haber existido antes una inicialización con los mismos parámetros.

Espero que se vea mejor con este ejemplo tomado de los apuntes de Cristian Haacks como una narración informal:

A begins! Send (A, m, B)
A ? S : A, {B, m}kas
S ? B : {A, m}kbs
B ends Send (A, m, B)

Así pues, decimos que es seguro si no existe la posibilidad de que se ejecute el B ends Send(A,m,B) sin que antes e haya ejecutado un A begins! Send(A,m,B). Para acabar, el ! indica que esta aserción se repite indefinidas veces, es decir que un evento begin puede corresponderse con un end repetidas veces. Un ejemplo de esto sería una firma digital, puesto que la firma se puede comprobar muchas veces y siempre será válida. Sin embargo, a veces interesa que solo se de una vez, para garantizar la frescura de la información y evitar replay attacks.

Para ello, se usan eventos inyectivos, que se modelan sin el ! y simplemente un begin puede corresponderse con un end, y nunca más. Para conseguir esto, los protocolos hacen uso de números de secuencia, nonces (number used once), timestamps o similares.

Realmente hay un poco más de chica por aquí detrás con cómo se propagan estos eventos por los canales y demás, pero vamos a dejarlo en que se considera seguro si esto ocurre, ya que en caso contrario significaría que el atacante puede forzar a B a ejecutar un end Send(A,m,B) sin que realmente A haya mandado el mensaje B, lo cual viola la autenticación.

También hay un poco más de teoría respecto a Spi-calculus y procesos seguros respecto a confidencialidad, que especifica qué procesos se pueden denominar así. Intuitivamente, son aquellos procesos en los que no existe ninguna manera de llegar a algo que escriba un secreto en un canal público mediante la semántica operacional de spi-calculus.

Ahora bien, después de este rollo, cómo nos lo montamos con ProVerif para especificar estas propiedades? Pues es bastante sencillo:

Las metas de confidencialidad, simplemente se especifican en la zona de declaraciones con una query tal que así:

query attacker: s.

Donde s es el valor que queremos que sea secreto. El problema es que ProVerif usa macros y los nombres son globales, así que si creamos dos nombres iguales en distintos procesos y hacemos una query, irá para los dos. Además, si usamos variables para las queries, siempre dará que el atacante puede obtenerlo mientras que no es necesariamente cierto.

Para este caso, lo que podemos hacer es generar un flag único y pedir a ProVerif que nos diga si el flag puede obtenerse. Por ejemplo, imaginemos la variable M que ha sido obtenida mediante tras leer de la red. Si queremos que sea secreta, deberíamos hacer algo como:

query attacker: M.
process (*otro_proceso*)|(in(net,M))

Pero entonces ProVerif nos dirá que el atacante puede obtener M, ya que es una variable. Lo que haríamos sería:

query attacker:flagM.
process (*otro_proceso*)|(in(net,M);out(M,flagM);)

En este caso, si el atacante puede conocer M podrá leer del canal M, con lo que podrá obtener el flag y la query fallará. Si no, no podrá obtener el flag y no fallará.

Por otra parte, las aserciones de correspondencia se transforman en eventos, y podemos especificar que un evento debe estar precedido por otro. Un ejemplo sacado de mis códigos de ProVerif sería:

query evinj : endSendToInit(x,y,z) ==> evinj : beginSendToInit(x,y,z).
query evinj : endSendToResp(x,y,z) ==> evinj : beginSendToResp(x,y,z).
query evinj : endAckToInit(x,y,z) ==> evinj : beginAckToInit(x,y,z).
query evinj : endAckToResp(x,y,z) ==> evinj : beginAckToResp(x,y,z).

Aquí estamos diciendo que el evento endSendToInit(x,y,z) debe estar precedido por el evento beginSendToInit(x,y,z), y lo mismo para el resto de eventos. La palabra clave evinj indica que se trata de una correspondencia inyectiva, es decir uno a uno. Si usaramos ev en su lugar se trataría de correspondencia no inyectiva, muchos a uno.

Por último, comentar que es posible especificar en ProVerif la propiedad de no interferencia ( non-interference ), que significa que un atacante no será capaz de distinguir una ejecución del protocolo de otra cambiando los valores de las variables de las que deseamos preservar dicha propiedad.

Dicho más sencillo: que no se puede obtener ninguna información de las variables, ni siquiera si son iguales o distintas de una ejecución a la otra. Por ejemplo, esto no cumpliría dicha propiedad:

P(x) = out(net,{x}k);

Puesto que si {x1}k es igual a {x2}k, entonces x1 es igual a x2. Para resolverlo usaríamos cifrado no determinístico, que simplemente añade una parte aleatoria al mensaje. Algo así:

P(x) = new n; out(net,{(x,n)}k);

De esta forma, como n es aleatorio y presumiblemente diferente cada vez, que el texto cifrado sea igual no implica que el contenido lo sea.

Para especificar esta propiedad, en ProVerif escribiremos por ejemplo:

noninterf x1,x2.

Y luego modelaremos dos procesos en paralelo, uno con x1 y otro con x2. Tras ejecutar ProVerif (que ya veremos cómo se hace en otro post) nos dirá si se puede distinguir entre ellos o no.

Esto es todo de momento... sigo dandoos el coñazo con teoría que puede que no se entienda mucho , pero en el próximo post explicaré cómo ejecutar ProVerif y un pequeño ejemplo con varias cosas juntas, y después en el siguiente analizaremos el modelo de TLS que puse hace un tiempo.

Si alguien está leyendo esto, que comente si se entiende más o menos o algo ( Y quien lo esté leyendo es todo un campeón xD)

Un archivo fuente de ProVerif puede estar en spi-calculus o mediante cláusulas de Horn. Nosotros solo vamos a ver spi-calculus entre otras cosas porque yo de cláusulas de Horn ni idea . Los archivos fuente .pi tienen varias partes que vamos a ver por separado:

Declaración de nombres

Generalmente al inicio del código se declaran los nombres que se van a usar en el modelo. Esto suele incluir los canales de comunicación públicos, identificadores de usuario, tags para los mensajes, etc.

La sintaxis es sencilla: [private] free nombre. declararía nombre, donde el atributo opcional private indica que solo se puede usar si está explícitamente escrito en el modelo. Es decir, el atacante no tendrá acceso a dicho nombre si anteponemos la palabra private en su declaración.

Constructores y reglas de reducción

Estos son un mecanismo genérico para modelar operaciones como cifrado/descifrado, hashes, derivación de claves a partir del identificador de agente y otros. Básicamente, definimos un constructor como una función de varias variables, y una regla de reducción para poder deshacer lo que hizo el constructor.

La sintaxis es como sigue:

fun constructor/n.
reduc destruct(construct(...),...) = ... .

Con un ejemplo queda claro enseguida. Lo siguiente sería para definir cifrado/descifrado de forma simétrica:

fun encrypt/2
reduc decrypt(encrypt(x,y),y) = x.

Como se puede ver, definimos un constructor con 2 parámetros, y definimos un destructor de forma que si aplicamos decrypt(c,y) donde c ha sido construido como encrypt(x,y), entonces devuelve x. Es decir, y en este caso sería la clave, y x el mensaje a cifrar.

Para un hash, simplemente definiríamos un constructor con 1 único mensaje y sin definir un destructor. De esta forma tenemos una función no invertible perfecta y sin colisiones.

Macros de procesos

Se pueden definir macros de procesos para hacer el código más legible. La sintaxis es:

let proceso = <codigo_del_proceso>.

De esta forma, podemos definir los distintos roles del protocolo en macros separadas y luego juntarlas en el proceso principal.

Proceso principal

Finalmente, el proceso principal se define de la siguiente forma:

process
...

Donde en ... podemos referirnos a los procesos creados mediante macros por su nombre, y ProVerif los sustituirá directamente ahí, de forma textual. No se debe pensar en ellos en forma de funciones, sino simplemente que se reemplazará cualquier aparición de su nombre por el contenido definido en la macro.

Consultas

Además, ProVerif permite especificar consultas, que normalmente ponemos después de las declaraciones de nombres. Esto nos permite verificar si se cumplen los objetivos del protocolo, pero lo veremos en otro post cuando veamos cómo modelar los objetivos.

Diferencias con spi-calculus

Existen algunas diferencias con spi-calculus en la sintaxis, por ejemplo en la forma de escribir/leer a/de un canal de comunicación, la forma de dividir tuplas y algunas cosillas más. Lo mejor es que veamos un ejemplo del protocolo que pusimos en el post anterior para aclarar todo.

Ejemplo

Veamos cómo modelar en ProVerif el protocolo simple del post anterior. La narración informal del protocolo era tal que así:

A->B: (M,A)
B->A: N
A->B: {| #(M,B,N) |}sA
En primer lugar, generaremos los nombres de usuario, el canal de comunicación y los constructores:

free net, A,B,Sign.
fun hash/1.
fun pencrypt(x,enc(y)).
reduc pdecrypt(pencrypt(x,enc(y)),dec(y)).

Como se puede adivinar, pencrypt/pdecrypt definen la criptografía de clave pública que usaremos, donde enc() y dec() identifican la parte de cifrado y la parte de descifrado de un par de claves.

Seguidamente, veremos el proceso A y B:

let procA = new m;out(net,(m,A));in(net,n);out(net,pencrypt((m,n,B),enc(kpa) ).
let procB = in(net,(m,=A));new n;out(net,n);in(net,signed); let (=m,=n,=B) = pdecrypt(signed,dec(kpa)) in 0.

En este caso, he asumido que kpa es el par de claves de A y lo he usado directamente en los procesos, aunque aun no lo hemos generado. Como se puede ver, es mucho menos engorroso que spi-calculus directamente, puesto que permite especificar coincidencias en los mensajes leídos del canal, leer directamente varios valores sin tener que hacer primero el inp y luego el split, etcétera.

Finalmente, nos falta definir el proceso que los junte:

process
new kpa; ( procA | procB )

Con esto tendríamos modelado el protocolo, aunque no habría ningún objetivo especificado y realmente ProVerif no hará nada.

En los próximos posts veremos cómo modelar los objetivos y cómo leer la salida de ProVerif, que es capaz incluso de dar ataques en algunas ocasiones.

Empezamos con una manera informal de definir protocolos, seguimos con spi-calculus, y finalmente vemos la sintaxis concreta de ProVerif. En el siguiente post tocará ver cómo modelamos los objetivos de los que hablamos en el post anterior, y en el último veremos paso por paso un modelo concreto.

Narraciones informales

Veamos primero como narrar de forma informal los protocolos criptográficos. En primer lugar, necesitamos una serie de primitivas para definir los mensajes:

• Tuplas: (m1,m2,...,mn)
• Cifrado simétrico: { M }k
• Cifrado asimétrico: {| M |}pk
• Hashes: #( )

Además de esto, necesitamos nonces, que son números de un sólo uso que (en nuestro modelo) son imposibles de adivinar, y claves, que también asumimos inadivinables.

Con esto, podemos por ejemplo modelar el siguiente protocolo:

A->B: (M,A)
B->A: N
A->B: {| #(M,B,N) |}sA

Donde sA es la clave privada de A para realizar firmas criptográficas y N es un nonce que B genera para que la firma de A sea válida solo una vez. En caso de no usar ese nonce, la firma podría haber sido mandada por un atacante ( replay atack ). Imagina este protocolo:

A->B: (M,A)
B->A: Sign
A->B: {| #(M,B) |}sA

En lugar de un nonce, B solo pide la firma de A. En este caso, un atacante podría reenvíar lo mismo más tarde...y por ejemplo B es tu banco y M un mensaje "pagame 1.000.000$" ya la hemos liado

Creo que con esto quedan claras las narraciones informales, que nos definir un protocolo pero dejan muchos detalles implícitos: comprobaciones al recibir los mensajes, número de agentes en el protocolo, quién y cuándo se generan los mensajes (M,N en este caso), etcetera.

Así pues, necesitamos de un formalismo para definir mejor los protocolos de forma que todo quede tan explícito como sea posible: spi-calculus.

Spi-calculus

El lenguaje spi-calculus está definido por una serie de mensajes, procesos que se pueden componer en serie o en paralelo y una semántica operacional que define cómo evolucionan dichos procesos. Por ejemplo, si se tiene un proceso que escribe en un canal dado, y se tiene otro que lee de dicho canal en paralelo en la variable x, entonces la semántica operacional nos dice que en un paso se puede ir de esta construcción a una en la que sustituiremos todos los valores de la variable x detrás de la lectura del canal en el segundo proceso por el valor escrito por el primero.

No voy a explicar aquí todo el spi-calculus, simplemente os dejo este link a un resumen del mismo, y ahora pongo un ejemplo porque el parrafo anterior queda bastante confuso. El siguiente fragmento de código sería el equivalente al protocolo anterior:

Pinit(a,b,sa)= new m; out net (m,a); inp net x; if x=Sign then out net {| #(m,b) |}
Presp(b,a,pa)=inp net x; split x is (m,a); out net Sign; inp net x; decrypt x is {| z |}pa^-1; if z = #(m,b) stop
Pprotocolo = new a;new b;new kpa; new kpb; !Pinit(a,b,enc(kpa)) | !Pinit(b,a,enc(kpb)) | !Presp(b,a,dec(kpa)) | !Presp(a,b,dec(kpb))

De esta forma, tenemos que Pinit es un proceso que genera un mensaje, lo manda a la red, espera a recibir Sign y manda a la red una firma sobre el hash de (m,b). Presp realiza la otra parte del protocolo, y Pprotocolo une todo dando los parámetros adecuados para que pueda haber infinitas sesiones donde ambos agentes a y b puedan funcionar tanto de iniciador como de receptor.

Echando un ojo a la semántica operacional, se puede ver que yendo paso a paso podemos ejecutar el protocolo gracias a spi-calculus. Espero que con este ejemplo y el documento con el resumen de la sintaxis y la semántica se medio entienda, aunque realmente no vamos a usar spi-calculus como tal sino una versión modificada que paso a explicar en otro post ya que se está haciendo demasiado largo y queda un poquito sobre el lenguaje usado por ProVerif.

Sé que este post ha podido quedar demasiado teórico y muy resumido, pero lo interesante está por llegar. En el próximo modelaremos el mismo protocolo mediante ProVerif, pero sin añadir objetivos de seguridad al mismo. Después veremos cómo modelar los objetivos y los añadiremos al modelo, para poder comprobar su seguridad.

En este primer post introduciremos las principales propiedades de los protocolos y el modelo que usamos. En el próximo post veremos rápidamente cómo definir protocolos mediante narraciones informales, la sintaxis del lenguaje spi-calculus para modelado de protocolos criptográficos, y la generalización utilizada en ProVerif. Después de esto, vendrá un post sobre cómo modelar las propiedades básicas en spi y ordenar consultas en ProVerif. Finalmente, despiezaremos en un último post una parte del modelo de TLS, sin implementar ningún mensaje opcional ni
resumen de sesiones.

Objetivos de los protocolos criptográficos

La siguiente lista muestra unos cuantos objetivos básicos en sistemas de seguridad:

• Confidencialidad: Este objetivo se traduce en que un atacante no pueda obtener información sobre ciertos datos del protocolo. Existen dos nociones, la estandar que simplemente implica que no se puede obtener el contenido de los mensajes, y otra más fuerte ( non-interference ) que implica que no se puede deducir nada sobre los mensajes, ni siquiera si dos mensajes mandados tienen el mismo contenido.

• Autenticación: Trata de asegurar que el origen del mensaje es realmente quien dice ser ( autenticación de origen). También existe autenticación de usuario, verificando que un usuario es quien dice ser.

• Integridad: Asegura que los datos no han sido modificado

• No repudio: Asegura que el origen de los datos no pueda negar que los haya enviado ( no repudio de origen) o el destino no pueda negar que los haya recibido ( no repudio de destino ).

Existen otras metas, pero estas dan una idea del tipo de objetivos que puede tener un protocolo de seguridad. Por supuesto cada protocolo está pensado para una situación concreta y puede que tenga algunos de estos objetivos o no.

Modelo black box ( Dolev-Yao )

Para poder verificar las propiedades de un protocolo formalmente, necesitamos modelar dicho protocolo de alguna forma. En nuestro caso usaremos el modelo Dolev-Yao. Este modelo asume que la criptografía es perfecta y que el atacante puede interceptar, modificar o eliminar cualquier mensaje transmitido. Es decir, el atacante controla completamente el canal de comunicación.

La criptografía idealizada que asume este modelo tiene como consecuencia que sin la clave no se puede obtener ninguna información al respecto del contenido, ni tampoco modificarlo. Por tanto la integridad de los mensajes está asegurada... aunque no su origen. Además, las claves son imposibles de adivinar o extraer del texto cifrado y los números aleatorios y los hashes son perfectos.

Por tanto, mediante este modelo solo podremos encontrar fallos independientes de la criptografía. Fallos del protocolo en sí, en la lógica o en la interpretación de mensajes cifrados con la misma clave pero distintos formatos, etc

De momento lo dejamos aquí, el próximo post como he dicho al principio, narraciones informales, spi-calculus y spi-calculus genérico de ProVerif.

Esta semana nos han devuelto las soluciones y como está bastante completa, con la única pega de que modelamos una única continuación de cada sesión en lugar de (potencialmente) infinitas, la he subido para quien le pueda interesar. Modificar eso es sencillísimo y solo es añadir un signo de exclamación (replicación infinita del proceso) delante del comando que mete el identificador de sesión en un canal privado a modo de base de datos tanto en el cliente como en el servidor.

Es posible que más adelante escriba una serie de posts sobre cómo funciona ProVerif, o suba un documento que probablemente me haga para mi propio uso antes del examen de esta asignatura, a modo resumen de todo lo dado.

El modelo, aquí. Lo hice conjuntamente con un compañero, pero ha dado permiso para publicarlo en la web del profesor con nuestros nombres y aquí no creo que tenga ningún problema

La sintaxis es algo compleja si no se conoce, si estáis interesados podéis consultar la web de la asignatura, donde además hay otras dos soluciones; otra opción es esperar a que ponga algún ejemplo explicado más adelante.

Si alguien está interesado que lo diga en los comentarios y así lo tendré presente .