About one mistake
Maybe I'm wrong, but I firmly hold the opinion that some errors are no less interesting than the projects in which they occurred. I want to tell about one project in which I took part for a long time. About how it would seem the correct use of cryptographic tools, led to the emergence of vulnerability, depriving the rest of the cryptography of any meaning.
I will say right away that I do not consider myself a qualified specialist in the field of cryptography. I dealt with cryptographic algorithms when the situation left me no other choice. Of course, it would be better if someone who was more knowledgeable in the matter would be engaged in these works, but it turned out that I had to deal with them. In any case, I hope that my story will be interesting.
This story took place in the mid-90s. I studied at the 4th year at KAI , while at the same time working as part of the PM department. I remember that I wrote something on FoxBase for one of the local "candle factories", together with several employees of the institute. The work at the department itself contributed to the fact that I was constantly in sight and, at one fine moment, I was offered to participate in a new project related to the development of a hardware tool for cryptography. Of course, I agreed.
Our group consisted of a pair of well-qualified cryptologists, electronics engineers and programmers. I, as a young specialist, was engaged in HAL th. Nothing special, C ++ and some x86 assembler. Subsequently, we, with the whole group, were very successfully employed in the RCI NB RT .
')
Here is what one of our products looked like ( ISA card with a removable key):
In addition to the main purpose - streaming encryption by gamming , it could also be used as a qualitative pseudo-random number generator. The main feature of this device was the impossibility of intercepting key data using software bookmarks.
Everything was connected as follows:
Inside the key was a regular ROM- card:
When encryption was performed, 16 bytes of the key (in a row) were read from the ROM at the specified address in the Device, after which, based on this key and random synchronization, the gamma used for encryption was generated. The key itself on the PC has never been transmitted.
I don’t remember who had the idea (perhaps it was me) that if you choose a key from ROM not in a row, but byte-by-by (controlling the sampling of each byte), then with the help of various permutations, you can get much more keys. It was a really awful idea. Quietly and imperceptibly, a hole was formed in the architecture of the hardware-software complex, which allows software to read the contents of the entire ROM of the key.
Fortunately, this vulnerability was noticed and fixed in time, but several devices had to be redone.
With this small article I want to warn the Reader against the frivolous attitude to issues related to cryptography. Cryptography is insidious and vulnerabilities can easily arise where you least expect them. However, I do not call “non-professionals” to abandon the use of cryptography, just as is done in this article .
Only experience and maximum attention to the task can help in detecting errors like the one described above. And if in this direction does not work, then the experience will come from nowhere.
I will say right away that I do not consider myself a qualified specialist in the field of cryptography. I dealt with cryptographic algorithms when the situation left me no other choice. Of course, it would be better if someone who was more knowledgeable in the matter would be engaged in these works, but it turned out that I had to deal with them. In any case, I hope that my story will be interesting.
This story took place in the mid-90s. I studied at the 4th year at KAI , while at the same time working as part of the PM department. I remember that I wrote something on FoxBase for one of the local "candle factories", together with several employees of the institute. The work at the department itself contributed to the fact that I was constantly in sight and, at one fine moment, I was offered to participate in a new project related to the development of a hardware tool for cryptography. Of course, I agreed.
Of course, it was not so easy
I was given a task. They told in detail about the developed Device and asked to prepare its description for the impending exhibition. For one night I worked at the institute (I didn’t have a computer at home then), on Turbo Pascal with assembler inserts I prepared a “presentation” with EGA- video effects, a bunch of text and pictures painted by Line and Fill ami Potential employer slightly ofigel from the diligence shown by me and the question of my employment was resolved positively.
Our group consisted of a pair of well-qualified cryptologists, electronics engineers and programmers. I, as a young specialist, was engaged in HAL th. Nothing special, C ++ and some x86 assembler. Subsequently, we, with the whole group, were very successfully employed in the RCI NB RT .
')
Here is what one of our products looked like ( ISA card with a removable key):
In addition to the main purpose - streaming encryption by gamming , it could also be used as a qualitative pseudo-random number generator. The main feature of this device was the impossibility of intercepting key data using software bookmarks.
Everything was connected as follows:
Inside the key was a regular ROM- card:
When encryption was performed, 16 bytes of the key (in a row) were read from the ROM at the specified address in the Device, after which, based on this key and random synchronization, the gamma used for encryption was generated. The key itself on the PC has never been transmitted.
I don’t remember who had the idea (perhaps it was me) that if you choose a key from ROM not in a row, but byte-by-by (controlling the sampling of each byte), then with the help of various permutations, you can get much more keys. It was a really awful idea. Quietly and imperceptibly, a hole was formed in the architecture of the hardware-software complex, which allows software to read the contents of the entire ROM of the key.
Details
Retrieving the contents of the ROM with the availability of byte-key loading is really easy. For example, to determine the value of any byte of the address space of a key, it is sufficient to form a key consisting of 16 bytes loaded from the same address. Then, on this key, you need to encrypt any preselected sequence (for example, a sequence of zeros).
Since, with this method of loading a key, there are only 256 possible options, a table of encryption results can be built in advance. From this table, you can easily determine which byte the key consists of. In the same way, slowly but surely, you can read all the remaining contents of the hardware key.
Since, with this method of loading a key, there are only 256 possible options, a table of encryption results can be built in advance. From this table, you can easily determine which byte the key consists of. In the same way, slowly but surely, you can read all the remaining contents of the hardware key.
Fortunately, this vulnerability was noticed and fixed in time, but several devices had to be redone.
With this small article I want to warn the Reader against the frivolous attitude to issues related to cryptography. Cryptography is insidious and vulnerabilities can easily arise where you least expect them. However, I do not call “non-professionals” to abandon the use of cryptography, just as is done in this article .
Only experience and maximum attention to the task can help in detecting errors like the one described above. And if in this direction does not work, then the experience will come from nowhere.
Source: https://habr.com/ru/post/181954/
All Articles