Содержание Введение …(см на отдельном файле ……………….……………………………………………………………3

Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security

О минимальной длине ключа для симметричных шифров, обеспечивающей необходимую степень стойкости

A Report by an Ad Hoc Group of Cryptographers and Computer Scientists

Отчет группы криптографов и компьютерных исследователей

ABSTRACT

Encryption plays an essential role in protecting the privacy of electronic information against threats from a variety of potential attackers. In so doing, modern cryptography employs a combination of conventional or symmetric cryptographic systems for encrypting data and public key or asymmetric systems for managing the keys used by the symmetric systems. Assessing the strength required of the symmetric cryptographic systems is therefore an essential step in employing cryptography for computer and communication security

АННОТАЦИЯ

Шифрование играет существенную роль в сохранении в тайне электронной секретной информации от угроз со стороны потенциальных взломщиков. Для этого современная криптография использует комбинацию обычных (симметричных) криптографических систем для шифрования данных и открытых (ассиметричных) ключей для управления ключами симметричных систем. Следовательно, оценка стойкости симметричной системы есть существенный шаг в применении криптографии для компьютерной и коммуникационной безопасности.

Technology readily available today (late 1995) makes brute-force attacks against cryptographic systems considered adequate for the past several years both fast and cheap. General purpose computers can be used, but a much more efficient approach is to employ commercially available Field Programmable Gate Array (FPGA) technology. For attackers prepared to make a higher initial investment, custom-made, special-purpose chips make such calculations much faster and significantly lower the amortized cost per solution.

Технологии, легко доступные сегодня (после 1995 г.) делают силовые атаки на криптографические системы быстрыми и дешевыми. Для этой цели могут быть использованы компьютеры общего назначения, но намного эффективнее использовать Набор Программируемых Чипов (НПЧ). Для взломщика, способного сделать большие начальные инвестиции, специальный чип может производить такие вычисления намного быстрее, и цена решения будет значительно дешевле.

As a result, cryptosystems with 40-bit keys offer virtually no protection at this point against brute-force attacks. Even the U.S. Data Encryption Standard with 56-bit keys is increasingly inadequate. As cryptosystems often succumb to `smarter' attacks than brute-force key search, it is also important to remember that the keylengths discussed here are the minimum needed for security against the computational threats considered.

В результате, с этой точки зрения, криптосистемы с 40-битовыми ключами фактически не обеспечивают защиты от силовой атаки. Даже американский государственный стандарт шифрования данных DES с 56-битовыми ключами является недостаточно надежным. Так как криптосистемы болеее подвержены взлому, чем силовой атаке, то важно помнить, что обсуждаемая длина ключа является минимально необходимой для обеспечения безопасности от вычислительных угроз.

Fortunately, the cost of very strong encryption is not significantly greater than that of weak encryption. Therefore, to provide adequate protection against the most serious threats - well-funded commercial enterprises or government intelligence agencies - keys used to protect data today should be at least 75 bits long. To protect information adequately for the next 20 years in the face of expected advances in computing power, keys in newly-deployed systems should be at least 90 bits

long.

К счастью, цена сильного шифрования не на много больше, чем цена слабого. Следовательно, для обеспечения необходимой защиты от наиболее серьезных угроз - крупных финансовых предприятий или иностранных разведслужб - ключи, используемые сегодня для защиты информации должны быть не менее 75-битовой дины. Для защиты информации на следующие 20 лет, перед лицом ожидаемого развития компьютерных мощностей, ключи в проектируемых системах должны быть не менее 90 битов.

1. Encryption Plays an Essential Role in Protecting the Privacy of Electronic Information

1. Шифрование играет существенную роль для сохранения в тайне секретной информации

1.1 There is a need for information security.

1.1 Необходимость защиты информации

Today, most forms of information can be stored and processed electronically. This means a wide variety of information, with varying economic values and privacy aspects and with a wide variation in the time over which the information needs to be protected, will be found on computer networks. Consider the spectrum:

1. Electronic Funds Transfers of millions or even billions of dollars, whose short term security is essential but whose exposure is brief;

2. A company's strategic corporate plans, whose confidentiality must be preserved for a small number of years;

3. A proprietary product (Coke formula, new drug design) that needs to be protected over its useful life, often decades; and

4. Information private to an individual (medical condition, employment evaluation) that may need protection for the lifetime of the individual.

Сегодня большинство форм информации могут быть записаны и обработаны в электронном виде. Это означает, что в компьютерных сетях может быть найдено большое разнообразие информации, с различными экономическими ценами и уровнями секретности, широким разнообразием во времени, в течение которого она должна быть секретной. Рассмотрим спектр:

• Международные переводы миллионов и, даже, миллиардов долларов, характеризующиеся коротким временем стойкости и существование которых непродолжительно.

• Стратегический план действий корпорации, секретность которого должна сохраняться в течение некоторого небольшого количества лет.

• Права на продукт (формула Коки, состав новых лекарств), которые должны быть защищены на всем протяжении существования и использования продукта, часто десятки лет.

• Информация принадлежащая частным лицам (состояние здоровья, зарплата) которые могут нуждаться в защите на все время жизни .

1.2 Encryption can provide strong confidentiality protection.

1.2 Шифрование может обеспечить сильную защиту

Encryption is accomplished by scrambling data using mathematical procedures that make it extremely difficult and time consuming for anyone other than authorized recipients - those with the correct decryption keys - to recover the plain text. Proper encryption guarantees that the information will be safe even if it falls into hostile hands.

Шифрование производится перемешиванием данных используя математические процедуры, которые делают его предельно сложным и времяпожирающим для всех, кто не является законным пользователем (обладающим необходимым ключом дешифрования для расшифрования исходного текста). Шифрование гарантирует, что информация будет в безопасности, даже если она попадет к неприятелю в руки.

The degree of protection obtained depends on several factors. These include: the quality of the cryptosystem; the way it is implemented in software or hardware (especially its reliability and the manner in which the keys are chosen); and the total number of possible keys that can be used to encrypt the information. A cryptographic algorithm is considered strong if:

1. There is no shortcut that allows the opponent to recover the plain text without using brute force to test keys until the correct one is found; and

2. The number of possible keys is sufficiently large to make such an attack infeasible.

Степень защиты зависит от нескольких факторов: качество криптосистемы, способы ее использования в программах и аппаратуре (особенно ее надежность и способ выбора ключей), общее количество возможных ключей. Криптографический алгоритм считается стойким, если :

1. Не существует короткого пути, позволяющего противнику получить исходный текст без использования силовой атаки

2. Количество возможных ключей значительно больше того, чтобы сделать такую атаку успешной

The sizes of encryption keys are measured in bits and the difficulty of trying all possible keys grows exponentially with the number of bits used. Adding one bit to the key doubles the number of possible keys; adding ten increases it by a factor of more than a thousand.

Размеры ключей шифрования измеряются в битах, а сложность перебора всех возможных ключей растет экспоненциально с ростом числа битов. Добавление одного бита к ключу удваивает количество возможных ключей, добавление 10 - увеличивает его более, чем в 1000 раз.

There is no definitive way to look at a cipher and determine whether a shortcut exists. Nonetheless, several encryption algorithms - most notably the U.S Data Encryption Standard (DES) - have been extensively studied in the public literature and are widely believed to be of very high quality. An essential element in cryptographic algorithm design is thus the length of the key, whose size places an upper bound on the system's strength.

Не существует простого способа взглянуть на шифрсистему и определить существует ли короткий путь. Тем не менее, некоторые алгоритмы - наиболее известен DES - интенсивно изучались в открытой литературе и в них можно быть увереными с высокой степенью доверия. Существенный элемент в разработке криптографического алгоритма это то, что длина ключа есть верхняя грань стойкости шифрсистемы.

Throughout this paper, we will assume that there are no shortcuts and treat the length of the key as representative of the cryptosystem's workfactor - the minimum amount of effort required to break the system. It is important to bear in mind, however, that cryptographers regard this as a rash assumption and many would recommend keys two or more times as long as needed to resist brute-force attacks. Prudent cryptographic designs not only employ longer keys than might appear to be needed, but devote more computation to encrypting and decrypting. A good example of this is the popular approach of using triple-DES: encrypting the output of DES twice more, using a total of three distinct keys.

Повсюду в этой статье мы будем полагать, что не существует короткого пути и считать длину ключа мерой стойкости системы - минимальное количество усилий требуемое для взлома системы. Важно помнить, что криптографы считают это слишком опрометчивым и многие из них рекомендуют ключи двойной или более длины, чем необходимо для защиты от силовой атаки. Предусмотрительный криптодизайн не только применяет более длинные ключи, чем необходимо, но и затрачивает больше вычислений для шифрования и дешифорования. Хороший пример этого - популярный подход к использованию тройного DES: шифрование выхода DES еще два раза используя в итоге разных ключа.

1.3 There are threats from a variety of potential attackers.

1.3 Существуют различные угрозы со стороны различных взломщиков

Threats to confidentiality of information come from a number of directions and their forms depend on the resources of the attackers. `Hackers,' who might be anything from high school students to commercial programmers, may have access to mainframe computers or networks of workstations. The same people can readily buy inexpensive, off-the-shelf, boards, containing Field Programmable Gate Array (FPGA) chips that function as `programmable hardware' and vastly increase the effectiveness of a cryptanalytic effort. A startup company or even a well-heeled individual could afford large numbers of these chips. A major corporation or organized crime operation with `serious money' to spend could acquire custom computer chips specially designed for decryption. An intelligence agency, engaged in espionage for national economic advantage, could build a machine employing millions of such chips.

Угрозы безопасности исходят со многих сторон и их формы зависят от ресурсов нападающего. Хакеры - которые могут быть кем угодно, от студента до программиста - могут иметь доступ к майнфреймам или сотням рабочих станций. Те же лица могут отхотно покупать недорогие бывшие в употреблении платы, содержащие наборы программируемых чипов (НПЧ), которые чрезвычайно повышают результативность криптоаналитического усилия. Начинающая компания, или даже хорошо оснащенный индивидуум, могут позволить себе приобрести большое количество таких чипов. Крупные компании или организованные криминальные группировки с «серьезными деньгами» могут заказать компьютерный чип специально разработанный для шифрования. Разведслужбы, занятые в промышленном шпионаже, могут построить машину, состоящую из миллиона таких чипов.

1.4 Current technology permits very strong encryption for effectively the same cost as weaker encryption.

1.4 Современные технологии дают сильное шифрование за туже цену, что и слабое

It is a property of computer encryption that modest increases in computational cost can produce vast increases in security. Encrypting information very securely (e.g., with 128-bit keys) typically requires little more computing than encrypting it weakly (e.g., with 40-bit keys). In many applications, the cryptography itself accounts for only a small fraction of the computing costs, compared to such processes as voice or image compression required to prepare material for encryption.

Особенность компьютерного шифрования в том, что малое увеличение стоимости вычислений может произвести огромное увеличение в безопасности. Очень стойкое шифрование сообщений (напр. с 128 - битовым ключом) обычно требует чуть больше вычислений, чем шифрование слабое (с 40-бтовыми ключами). Во многих приложениях криптография поглощает малую часть вычислительной мощности, по сравнению с такими процессами, как сжатие голоса или изображения, необходимые для подготовки материалов к шифрованию.

One consequence of this uniformity of costs is that there is rarely any need to tailor the strength of cryptography to the sensitivity of the information being protected. Even if most of the information in a system has neither privacy implications nor monetary value, there is no practical or economic reason to design computer hardware or software to provide differing levels of encryption for different messages. It is simplest, most prudent, and thus fundamentally most economical, to employ a uniformly high level of encryption: the strongest encryption required for any information that might be stored or transmitted by a secure system.

Одно из следствий такой единой цены состоит в том, что редко требуется ограничить определенным условием стойкость криптографии в зависимости от секретности информации. Даже если большинство информации в системе не является ни секретной ни финансово ценной, то нет практической или экономической причины для разработки аппаратуры или программ для обеспечения различных уровней шифрования для различных сообщений. Это простейший, наиболее осторожный (предусмотрительный) и т.о. фндаментально наиболее экономной, применить единый высокий уровень шифрования: сильное шифрование необходимо для любой информации, которая может быть сохранена или передана в защищенной системе.

2. Readily Available Technology Makes Brute-Force Decryption Attacks Faster and Cheaper

2. Легкодоступные технолгии делают силовую атаку быстрой и дешевой

The kind of hardware used to mount a brute-force attack against an encryption algorithm depends on the scale of the cryptanalytic operation and the total funds available to the attacking enterprise. In the analysis that follows, we consider three general classes of technology that are likely to be employed by attackers with differing resources available to them. Not surprisingly, the cryptanalytic technologies that require larger up-front investments yield the lowest cost per recovered key, amortized over the life of the hardware.

Особенности аппаратного обеспечения, используемого для проведения силовой атаки на шифровальный алгоритм зависят от количества криптоаналитических операций и свободных средств, доступных при нападении на предприятие. Ниже мы рассмотрим три главных класса, которые обычно применяются нападающими с различными ресурсами доступными им. криптоаналитические технологии, которые требуют больших начальных инвестиций, производят нижайшую цену за взломанный ключ, погашаемую за время износа аппаратуры.

It is the nature of brute-force attacks that they can be parallelized indefinitely. It is possible to use as many machines as are available, assigning each to work on a separate part of the problem. Thus regardless of the technology employed, the search time can be reduced by adding more equipment; twice as much hardware can be expected to find the right key in half the time. The total investment will have doubled, but if the hardware is kept constantly busy finding keys, the cost per key recovered is unchanged.

Такова природа силовой атаки, которая может быть бесконечно распараллелена. Необходимо использовать так много машин, как это возможно, выделяя каждой свою часть работы. Время поиска сокращается вдвое, если вдвое увеличить объем оборудования. Общие затраты должны удвоиться, но если аппаратура постоянно используется для поиска ключей, цена взлома за один ключ не изменится.

At the low end of the technology spectrum is the use of conventional personal computers or workstations programmed to test keys. Many people, by virtue of already owning or having access to the machines, are in a position use such resources at little or no cost. However, general purpose computers - laden with such ancillary equipment as video controllers, keyboards, interfaces, memory, and disk storage - make expensive search engines. They are therefore likely to be employed only by casual attackers who are unable or unwilling to invest in more specialized equipment.

На нижнем конце спектра находится использование неспециализированных персональных компьютеров или рабочих станций, запрограммированных для перебора ключей. Многие люди, благодаря обладанию или доступу к машинам, в состоянии использовать их ресурсы очнь дешево или бесплатно. Конечно, компьютеры общего назначения, нагруженные такими вспомогательными устройствами, как видеоконтроллеры, клавиатура, память и диски - делают поисковые вычисления дорогими. Следовательно, их будут применять только случайные лица, кто не может или не желает потратиться на более специализированное оборудование.

A more efficient technological approach is to take advantage of commercially available Field Programmable Gate Arrays. FPGAs function as programmable hardware and allow faster implementations of such tasks as encryption and decryption than conventional processors. FPGAs are a commonly used tool for simple computations that need to be done very quickly, particularly simulating integrated circuits during development.

Более эффективный технолгический подход заключается в применении наборов программируемых чипов (НПЧ). НПЧ функционируют как программируемое аппаратное обеспечение и позволяют быстрее, чем обычные процессоры, выполнять такие задачи, как шифрование и дешифрование. НПЧ - обычный инструмент для вычислений, которые необходимо выполнить быстро, в реальном масштабе времени.

FPGA technology is fast and cheap. The cost of an AT&T ORCA chip that can test 30 million DES keys per second is $200. This is 1,000 times faster than a PC at about one-tenth the cost! FPGAs are widely available and, mounted on cards, can be installed in standard PCs just like sound cards, modems, or extra memory.

НПЧ-технолгии быстрые и дешевые. Цена чипа АТ&Т ORCA, способного проверить 30 млн. ключей в секунду, составляет 200 долл. Это в 1000 раз быстрее, чем ПЭВМ, и, примерно, за 1/10 его цены. НПЧ легкодоступны, и установленные на плате могут применяться в стандартных ПЭВМ наподобие звуковых карт, модемов, или модулей памяти.

FPGA technology may be optimal when the same tool must be used for attacking a variety of different cryptosystems. Often, as with DES, a cryptosystem is sufficiently widely used to justify the construction of more specialized facilities. In these circumstances, the most cost-effective technology, but the one requiring the largest initial investment, is the use of Application-Specific Integrated Circuits (ASICs). A $10 chip can test 200 million keys per second. This is seven times faster than an FPGA chip at one-twentieth the cost.

НПЧ-технологии оптимальны в том случае, когда один и тот же инструмент должен применяться для атаки различных криптосистем. Часто, как в с лучае с DES, криптосистема достаточно широко используется, чтобы оправдать применение более специализированных устройств. В этом случае более выгодна технология, требующая, однако, больших начальных вложений - использование специализированных интегральных схем (СИС). 10-долларовый чип способен проверить 200 млн. ключей в секунду, что еще в 7 раз быстрее и в 20 раз дешевле, чем НПЧ.

Because ASICs require a far greater engineering investment than FPGAs and must be fabricated in quantity before they are economical, this approach is only available to serious, well-funded operations such as dedicated commercial (or criminal) enterprises and government intelligence agencies.

Поскольку СИС требует гораздо больше инженерных усилий, чем НПЧ, и оправдывает инвестиции далеко не сразу, то этот подход доступен только серьезным, хорошо оснащенным организациям.

3. 40-Bit Key Lengths Offer Virtually No Protection

3. В действительности, 40-битовые ключи не обеспечивают защиты

Current U.S. Government policy generally limits exportable mass market software that incorporates encryption for confidentiality to using the RC2 or RC4 algorithms with 40-bit keys. A 40-bit key length means that there are 2⁴⁰ possible keys. On average, half of these (2^39) must be tried to find the correct one. Export of other algorithms and key lengths must be approved on a case by case basis.

Современная политика правительства США запрещает экспортировать программное обеспечение, включая шифрование по алгоритмам RC2, RC4 с 40-битовыми ключами. 40-битовый ключ означает, что существуют 2⁴⁰ возможных ключей. В среднем, для нахождения правильного ключа приблизительно половина из них должна быть перебрана. Экспорт других алгоритмов должен быть специально разрешен.

Anyone with a modicum of computer expertise and a few hundred dollars would be able to attack 40-bit encryption much faster. An FPGA chip - costing approximately $400 mounted on a card - would on average recover a 40-bit key in five hours. Assuming the FPGA lasts three years and is used continuously to find keys, the average cost per key is eight cents.

Кто угодно, с современным компьютером и несколькими сотнями долларов способено взломать 40-битовое шифрование гораздо быстрее. Чип НПЧ - стоимостью около 400 долл. установленный на плате, сможет взломать 40-битовый ключ за 5 часов. Оценив работу НПЧ в течение трех лет для непрерывного поиска ключей, получим приблизительную оценку за ключ - 8 центов.

A more determined commercial predator, prepared to spend $10,000 for a set-up with 25 ORCA chips, can find 40-bit keys in an average of 12 minutes, at the same average eight cent cost. Spending more money to buy more chips reduces the time accordingly: $300,000 results in a solution in an average of 24 seconds; $10,000,000 results in an average solution in 0.7 seconds.

Более определенный коммерческий хищник, готовый потратить 10 000 долл. для установки 25 чипов ORCA, способен перебрать 40-битовые ключи в среднем за 12 минут, приблизительно по 8 центов за взломанный ключ. Затратив больше денег для покупки больше чипов укорачивает время соответственно 300 000 долл. - 24 сек., 10 000 000 долл - 0,7 сек.

As already noted, a corporation with substantial resources can design and commission custom chips that are much faster. By doing this, a company spending $300,000 could find the right 40-bit key in an average of 0.18 seconds at 1/10th of a cent per solution; a larger company or government agency willing to spend $10,000,000 could find the right key on average in 0.005 seconds (again at 1/10th of a cent per solution). (Note that the cost per solution remains constant because we have conservatively assumed constant costs for chip acquisition - in fact increasing the quantities purchased of a custom chip reduces the average chip cost as the initial design and set-up costs are spread over a greater number of chips.)

These results are summarized in Table I.

Как уже отмечалось, корпорация с соответствующими ресурсами может заказать гораздо более быстрый чип. Сделав это, компания затратившая 300 000 долл должна найти правильный ключ приблизительно за 0,18 секунд, при цене 1/10 цента за решение; более крупная компания или правительственная агентство способное потратить 10 000 000 долл. должно найти правильный ключ приблизительно за 0,005 секунд (опять 1/10 цента за решение). Заметим, что цена за решение является константой, потому, что мы предположили константой цену чипа. В действительности увеличение объема закупки уменьшает среднюю цену чипа, т.к. стоимость разработки делится на большее число чипов.

4. Even DES with 56-Bit Keys Is Increasingly Inadequate

4. Даже DES с 56-битовым ключом недостаточно сильный

4.1 DES is no panacea today.

4.1 DES уже не панацея

The Data Encryption Standard (DES) was developed in the 1970s by IBM and NSA and adopted by the U.S. Government as a Federal Information Processing Standard for data encryption. It was intended to provide strong encryption for the government's sensitive but unclassified information. It was recognized by many, even at the time DES was adopted, that technological developments would make DES's 56-bit key exceedingly vulnerable to attack before the end of the century.

Стандарт шифрования данных DES был разработан в 1970 г. IBM и АНБ и одобрен Американским правительством в качестве федерального стандарта обработки информации. Он предназначен для сильного шифрования правительственной важной, но негрифованной информации. Многим было понятно, еще когда DES разрабатывался, что технологический прогресс сделает 56-битовые ключи DES уязвимыми, еще до конца текущего века.

Today, DES may be the most widely employed encryption algorithm and continues to be a commonly cited benchmark. Yet DES-like encryption strength is no panacea. Calculations show that DES is inadequate against a corporate or government attacker committing serious resources. The bottom line is that DES is cheaper and easier to break than many believe

Сегодня DES - может быть, наиболее широко распространенный шифровальный алгоритм и продолжает им быть. DES- шифрование еще сильно, но оно не панацея. Вычисления показывают, что DES недостаточно сильный, от корпоративной или правительственной атаки, поддержанной серьезными ресурсами. DES взломать легче, чем многие думают.

As explained above, 40-bit encryption provides inadequate protection against even the most casual of intruders, content to scavenge time on idle machines or to spend a few hundred dollars. Against such opponents, using DES with a 56-bit key will provide a substantial measure of security. At present, it would take a year and a half for someone using $10,000 worth of FPGA technology to search out a DES key. In ten years time an investment of this size would allow one to find a DES key in less than a week.

Как описно выше, 40-битовое шифрование не обеспечивает защиты даже от случайного взломщика с ограниченным временем и ленивой машиной, либо нежелающего потратить несколько сотен долларов. Против таких оппонентов DES сможет обеспечить существенную защиту. Потребуется 1,5 года для всякого, кто используя 10 000 долл. на НПЧ-технологии найдет ключ. За десять лет инвестиции этого размера позволят найти ключ менее, чем за неделю.

The real threat to commercial transactions and to privacy on the Internet is from individuals and organizations willing to invest substantial time and money. As more and more business and personal information becomes electronic, the potential rewards to a dedicated commercial predator also increase significantly and may justify the commitment of adequate resources.

Реальная угроза коммерческим транзакциям и конфиденциальности в Интернете исходит от индивидуалов и организаций, желающих потратить значительное время и деньги. Поскольку все больше деловой и личной информации переводится в электронную форму, потенциальное вознаграждение коммерческому взломщику также увеличивается значительно и может оправдать затраты.

A serious effort - on the order of $300,000 - by a legitimate or illegitimate business could find a DES key in an average of 19 days using off-the-shelf technology and in only 3 hours using a custom developed chip. In the latter case, it would cost $38 to find each key (again assuming a 3 year life to the chip and continual use). A business or government willing to spend $10,000,000 on custom chips, could recover DES keys in an average of 6 minutes, for the same $38 per key.

Серьезная угроза - законный или незаконный бизнес сможет найти ключ приблизительноза 19 дней используя

или за 3 часа с помощью заказного чипа. В последнем случае, это будет стоить примерно 38 долл. за ключ (из расчета 3 лет непрерывной работы). Правительство или бизнес способный затратить 10 млн. долл. на заказные чипы сможет вскрыть DES ключ приблизительно за 6 минут, при той же цене 38 долл. за ключ.

At the very high end, an organization - presumably a government intelligence agency - willing to spend $300,000,000 could recover DES keys in 12 seconds each! The investment required is large but not unheard of in the intelligence community. It is less than the cost of the Glomar Explorer, built to salvage a single Russian submarine, and far less than the cost of many spy satellites. Such an expense might be hard to justify in attacking a single target, but seems entirely appropriate against a cryptographic algorithm, like DES, enjoying extensive popularity around the world.

На самом верхнем конце, организации - преимущественно правительственные разведываетельные агентства - способные вложить 300 млн. долл. могут взломать DES за 12 секунд. Затраты огромные, но не запредельные для разведывательного сообщества. Это меньше, чем стоит построенный специально для поднятия одной руской подводной лодки «подводный исследователь», и намного меньше, чем цена разведывательных спутников. Такие деньги трудно оправдать атакой на одну цель, но, по-видимому, приемлемо против алгоримов типа DES, широко применяемых во всем мире.

There is ample evidence of the danger presented by government intelligence agencies seeking to obtain information not only for military purposes but for commercial advantage. Congressional hearings in 1993 highlighted instances in which the French and Japanese governments spied on behalf of their countries' own businesses. Thus, having to protect commercial information against such threats is not a hypothetical proposition.

Это достаточное доказательство опасности представляемой таким агентствами в поисках получения информации не только для военных целей но для коммерческий целей. Слушания в Конгрессе в 1993 высветили пример, в котором правительства Франции и Японии следили за бизнесом в своих собственных странах. Т.о. защита коммерческой информации от таких угроз это не гипотетическое предположение.

4.3 The analysis for other algorithms is roughly comparable.

4.3 Анализ для других алгоритмов примерно одинаковых

The above analysis has focused on the time and money required to find a key to decrypt information using the RC4 algorithm with a 40-bit key or the DES algorithm with its 56-bit key, but the results are not peculiar to these ciphers. Although each algorithm has its own particular characteristics, the effort required to find the keys of other ciphers is comparable. There may be some differences as the result of implementation procedures, but these do not materially affect the brute-force breakability of algorithms with roughly comparable key lengths

Предыдущий анализ был сфокусирован на времени и деньгах, необходимых для дешифрования информации используя алгоритм RC4 с 40-битовым ключом или DES с 56-битовым ключом, но но результаты не были специфичными для каждого шифра. Хотя каждый алгоритм имеет свои особенности, усилия требуемые для нахождения ключа - сопоставимы. Возможны некоторые различия, но они не окажут значительный эффект на силовой взлом алгоритмов с примерно одинаковой длиной ключа.

Specifically, it has been suggested at times that differences in set-up procedures, such as the long key-setup process in RC4, result in some algorithms having effectively longer keys than others. For the purpose of our analysis, such factors appear to vary the effective key length by no more than about eight bits.

Особенно это касается времени процедур установки, такие, как длительная установка ключа в RC4, результат в некоторых алгоритмах, имеющих существенно более длинный ключ, чем другие. Для целей нашего анализа такие факторы длина ключа изменяется не более, чем на 8 битов.

5. Appropriate Key Lengths for the Future --- A Proposal

5. Соответствующая длина ключа на будущее - Предположения

Table I summarizes the costs of carrying out brute-force attacks against symmetric cryptosystems with 40-bit and 56-bit keys using networks of general purpose computers, Field Programmable Gate Arrays, and special-purpose chips.

Таблица 1 отражает стоимость силовой атаки против симметричной криптосистемы с 40-битовыми и 56-битовыми ключами, используя сети неспециализированных компьютеров, НПЧ и СИС технологии.

It shows that 56 bits provides a level of protection - about a year and a half - that would be adequate for many commercial purposes against an opponent prepared to invest $10,000. Against an opponent prepared to invest $300,000, the period of protection has dropped to the barest minimum of 19 days. Above this, the protection quickly declines to negligible. A very large, but easily imaginable, investment by an intelligence agency would clearly allow it to recover keys in real time.

Она показывает, что 56 бит обеспечивают степень защиты около 1,5 года - которая должна быть подходящим для многих коммерческих целей при оппоненте способнов вложить 10 000 долл. От оппонента, способного вложить 300 000 долл.период защиты сократится до малейшего минимума в 19 дней. Учитывая вышеизложенное, стойкость быстро падает до минимума. Очень большие, но близкие к реальным, инвестиции в соответствующие спецслужбы могут легко позволить ломать ключи в реальном времени.

What workfactor would be required for security today? For an opponent whose budget lay in the $10 to 300 million range, the time required to search out keys in a 75-bit keyspace would be between 6 years and 70 days. Although the latter figure may seem comparable to the `barest minimum' 19 days mentioned earlier, it represents - under our amortization assumptions - a cost of $19 million and a recovery rate of only five keys a year. The victims of such an attack would have to be fat targets indeed.

Какая длина ключа требуется на сегодняшний день? Для инвестора, чей бюджет лежит в диапазоне от 10 до 300 млн. время требуемое для перебора ключей соответствующих 75 битам лежит между 6 годами и 70 днями. Хотя последняя цифра очень похожа на наименьший минимум в 19 дней, она соответствует цене в 19 млн. долл. и уровню взлома 5 ключей в год. Жертва такой атаки должна представлять собой лакомый кусочек.

Because many kinds of information must be kept confidential for long periods of time, assessment cannot be limited to the protection required today. Equally important, cryptosystems - especially if they are standards - often remain in use for years or even decades. DES, for example, has been in use for more than 20 years and will probably continue to be employed for several more. In particular, the lifetime of a cryptosystem is likely to exceed the lifetime of any individual product embodying it.

Поскольку многие виды инфомации должны находиться в секрете долгий период времени, оценка не может быть ограничена защитой, требуемой сегодня. Также важно, что криптосистемы (особенно стандарты) часто предполагается использовать годы и даже десятилетия. DES, к примеру, использовался более 20 лет, и, возможно, будет использоваться еще. В частности, время жизни криптосистемы часто равно времени существования некоторого продукта, воплощающего ее.

A rough estimate of the minimum strength required as a function of time can be obtained by applying an empirical rule, popularly called `Moore's Law,' which holds that the computing power available for a given cost doubles every 18 months. Taking into account both the lifetime of cryptographic equipment and the lifetime of the secrets it protects, we believe it is prudent to require that encrypted data should still be secure in 20 years. Moore's Law thus predicts that the keys should be approximately 14 bits longer than required to protect against an attack today.

Грубая прикидка минимальной стойкости, как функции времени, может быть получена эмпирическим путем, часто называемым «законом Мура», который гласит, что вычислительные мощности при одной и той же стоимости удваиваются каждые 18 месяцев. Возьмите вместе время жизни криптографического оборудования, время жизни секретов и, как мы полагаем благоразумно потребовать, что шифрованные данные должны быть в безопасности еще 20 лет. В этом случае закон Мура означает, что ключи должны быть приблизительно на 14 битов длинее, чем требуется для предотвращения атаки сегодня.

Bearing in mind that the additional computational costs of stronger encryption are modest, we strongly recommend a minimum key-length of 90 bits for symmetric cryptosystems.

Необходимо помнить, что дополнительные вычислительные цены сильного шифрования скромные, поэтому мы очень рекомендуем минимальную длину ключа в 90 битов для симметричных систем.

It is instructive to compare this recommendation with both Federal Information Processing Standard 46, The Data Encryption Standard (DES), and Federal Information Processing Standard 185, The Escrowed Encryption Standard (EES). DES was proposed 21 years ago and used a 56-bit key. Applying Moore's Law and adding 14 bits, we see that the strength of DES when it was proposed in 1975 was comparable to that of a 70-bit system today. Furthermore, it was estimated at the time that DES was not strong enough and that keys could be recovered at a rate of one per day for an investment of about twenty-million dollars. Our 75-bit estimate today corresponds to 61 bits in 1975, enough to have moved the cost of key recovery just out of reach. The Escrowed Encryption Standard, while unacceptable to many potential users for other reasons, embodies a notion of appropriate key length that is similar to our own. It uses 80-bit keys, a number that lies between our figures of 75 and 90 bits.

Поучительно сравнить эти рекомендации с Федеральным стандартом обработки информации 46, DES, Федеральным стандартом обработки информации 185, Стандартом шифрования ЕЕS. DES был предложен 21 год назад и использует 56-битовый ключ. Применяя закон Мура и добавляя 14 битов получаем, что стойкость DES в том году, когда он был принят (1975 г.), сопоставима с 70-битовой системой сегодня. Подсчитано, что время в течение которого и что ключи могут быть перебраны в один день соответствуют инвестициям в 20 млн. долл. Наш 75-битовый расчет сегодня соответствует 61 биту в 1975 г., достаточно, чтобы вывести цену перебора ключей за достижимые пределы. EES пока неприемлем для многих потенциальных пользователей по многи причинам, воплощает понятие о соответствующей длине ключа, что похоже на наши. Он использует 80-битовые ключи, количество которых лежит между нашими значениями 75 и 90 битов.

About the Authors

Об авторах

Matt Blaze is a senior research scientist at AT&T Research in the area of computer security and cryptography. Recently Blaze demonstrated weaknesses in the U.S. government's `Clipper Chip' key escrow encryption system. His current interests include large-scale trust management and the applications of smartcards.

mab@research.att.com

Матт Блейз - старший исследователь в AT&T. Исследования в области компьютерной безопасности и криптографии. Недавно Блейз продемонстрировал слабость американской правительственной системы шифрования «Клиппер». В настоящее время он работает в области крупномасштабного управления доверием и приложений смарт-карт.

Whitfield Diffie is a distinguished Engineer at Sun Microsystems specializing in security. In 1976 Diffie and Martin Hellman created public key cryptography, which solved the problem of sending coded information between individuals with no prior relationship and is the basis for widespread encryption in the digital information age.

diffie@eng.sun.com

Уитфилд Диффи - заслуженный инженер в Sun Microsystems в области безопасности. В 1976 г. Диффи и Мартин Хеллман разработали криптографию с открытым ключом, которая решила проблемы обмена ключами по открытым каналам, создали базис для широкого применения шифрования в эпоху цифровой информации.

Ronald L. Rivest is a professor of computer science at the Massachusetts Institute of Technology, and is Associate Director of MIT's Laboratory for Computer Science. Rivest, together with Leonard Adleman and Adi Shamir, invented the RSA public-key cryptosystem that is used widely throughout industry. Ron Rivest is one of the founders of RSA Data Security Inc. and is the creator of variable key length symmetric key ciphers (e.g., RC4).

rivest@lcs.mit.edu

Рональд Райвест - профессор компьютерных наук Массачусетского Технологического института (МТИ) и заместитель директора Лаборатории Компьютерных наук МТИ. Райвест, совместно с Леонардом Эйдельманом и Эди Шамиром предложили криптосистему с открытым ключом, которая широко используется в индустрии. Рон Райвест - один из основателей компании RSA Data Security Inc. и разработчик серии алгоритмов шифрования с симметричным ключом различной длины (например RC4).

Bruce Schneier is president of Counterpane Systems, a consulting firm specializing in cryptography and computer security. Schneier writes and speaks frequently on computer security and privacy and is the author of a leading cryptography textbook, Applied Cryptography, and is the creator of the symmetric key cipher Blowfish.

schneier@counterpane.com

Брюс Шнейер - президент «Counterpane Systems» - консультационной фирмы специализирующейся в области криптографии и компьютерной безопасности. Шнейер много пишет и говорит о компьютерной защите и безопасности, он автор популярной книги «Прикладная криптография» и создатель симметричного алгоритма шифрования «Blowfish».

Tsutomu Shimomura is a computational physicist employed by the San Diego Supercomputer Center who is an expert in designing software security tools. Last year, Shimomura was responsible for tracking down the computer outlaw Kevin Mitnick, who

electronically stole and altered valuable electronic information around the country.

tsutomu@sdsc.edu

Цутоми Шимомура - специалист в вычислительной физике, работает в Суперкомпьютерном центре в Сан-Диего в качестве эксперта по созданию программных средств защиты. В прошлом году Шимомура организовывал операцию по поимке компьютерного нарушителя Кевина Митника, который воровал различную электронную информацию по всей стране.

Eric Thompson heads AccessData Corporation's cryptanalytic team and is a frequent lecturer on applied crytography. AccessData specializes in data recovery and decrypting information utilizing brute force as well as `smarter' attacks. Regular clients include the FBI and other law enforcement agencies as well as corporations.

eric@accessdata.com

Эрик Томсон - возглавляет криптоаналитическую команду корпорации «AccessData» («Доступ к данным») и популярный лектор по прикладной криптографии. Компания AccessData специализируется в области взлома данных и дешифрования информации методом «силовой атаки». Постоянными клиентами компании являются ФБР и другие правоохранительные органы и компании.

Michael Wiener is a cryptographic advisor at Bell-Northern Research where he focuses on cryptanalysis, security architectures, and public-key infrastructures. His influential 1993 paper, Efficient DES Key Search, describes in detail how to cons-

truct a machine to brute force crack DES coded information (and provides cost estimates as well).

wiener@bnr.ca

Майкл Винер - криптографический советник компании Bell-Northern Research, где он занимается криптоанализом, архитектурой безопасности и открытыми ключами. Под его влиянием 1993 газеты, эффективный поиск ключей DES, детальное описание машины для силовой атаки на DES-шифрованную информацию.

ACKNOWLEDGEMENT

The authors would like to thank the Business Software Alliance, which provided support for a one-day meeting, held in Chicago on 20 November 1995

БЛАГОДАРНОСТИ

Авторы выражают свою признательность Ассоциации производителей программного обеспечения Business Software Alliance за ее поддержку в подготовке однодневного семинара прошедшего в Чикаго 20 ноября 1995 г.

23287

21436

Тип нападающего

Бюджет

Инструмент

Время и цена за взломанный ключ

Длина необходимая для защиты

40 бит

56 бит

Пеший хакер

малый

мусорное машинное время

1 неделя

невозможно

45

400 долл.

FPGA

5 часов ($0.08)

38 лет ($5,000)

50

Малый бизнесс

10 тыс. долл.

FPGA

12 минут ($0.08)

556 дней ($5,000)

55

Средний бизнес

300 тыс. долл

FPGA or

ASIC

24 секунды

($0.08)

.18 секунд ($0.001)

19 дней ($5,000)

3 часа ($38)

60

Крупная компания

10 млн. долл.

FPGA

или

ASIC

.7 секунд ($0.08)

0,005 секунд ($0.001)

13 часов ($5,000) .6 минут ($38)

70

Спецслужбы

300 млн. долл.

ASIC

.0002 seconds ($0.001)

12 seconds ($38)

75

2. The AES-CBC Cipher Algorithm and Its Use with Ipsec (Алгоритм шифрования AES-CBC и его применение с IPSec)

 Abstract

   This document describes the use of the Advanced Encryption Standard (AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . .  2

       1.1.  Specification of Requirements. .  3

   2.  The AES Cipher Algorithm . . . . . . . .  3

       2.1. Mode . . . . . . . . . . . . . . . . . . . . . . .  3

       2.2.  Key Size and Number of Rounds . 4

       2.3.  Weak Keys. . . . . . . . . . . . . . . . . .  4

       2.4.  Block Size and Padding. . . . . . . .  4

       2.5.  Additional Information . . . . . .  4

      2.6. Performance. . . . . . . . . . . . . . .. . .  5

   3.  ESP Payload  . . . . . . . .. . . . . . . . . . . .  5

       3.1.  ESP Algorithmic Interactions . . .  6

       3.2.  Keying Material. . . . . . . . . . . . . .  6

   4.  Test Vectors . . . . . . . . . . . . . . . . . . . .  6

   5.  IKE Interactions . . . . . . . . . . . . . . . . 10       5.1.  Phase 1 Identifier. . . . . . . . . . . . 10       5.2.  Phase 2 Identifier. . . . . . . . . . . . . 10

      5.3.  Key Length Attribute . . . . . . . . . 10

      5.4.  Hash Algorithm Considerations . 10

   6.  Security Considerations  . . . . . . . . . . 11

   7.  IANA Considerations  . . . . . . . . . . . . 11

   8. Intellectual Property Rights Statement11

   9. References . . . . . . . . . . . . . . . . . . . . . 12

       9.1.  Normative References . . . . . . . 12

       9.2.  Informative References . . . . . . 12

   10. Acknowledgments  . . . . . . . . . . . . . 13

   11. Authors' Addresses . . . . . . . . . . . . . 14

1.  Introduction

   As the culmination of a four-year competitive process, NIST (the National Institute of Standards and Technology) has selected the AES (Advanced Encryption Standard), the successor to the venerable DES (Data Encryption Standard). The competition was an open one, with public participation and comment solicited at each step of the process. The AES [AES], formerly known as Rijndael, was chosen from a field of five finalists.

   The AES selection was made on the basis of several characteristics: 

      +  security

      +  unclassified

      +  publicly disclosed

      +  available royalty-free, worldwide

      +  capable of handling a block size of at least 128 bits

      +  at a minimum, capable of handling key sizes of 128, 192, and 256 bits

      +  computational efficiency and memory requirements on a variety of software and hardware, including smart cards

      +  flexibility, simplicity and ease of implementation

   The AES will be the government's designated encryption cipher. The expectation is that the AES will suffice to protect sensitive (unclassified) government information until at least the next century. It is also expected to be widely adopted by businesses and financial institutions.

   It is the intention of the IETF IPsec Working Group that AES will eventually be adopted as the default IPsec ESP cipher and will obtain the status of MUST be included in compliant IPsec implementations. 

   The remainder of this document specifies the use of the AES within the context of IPsec ESP. For further information on how the various pieces of ESP fit together to provide security services, refer to [ARCH], [ESP], and [ROAD].

1.1.  Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that appear in this document are to be interpreted as described in [RFC-2119].

2.  The AES Cipher Algorithm

   All symmetric block cipher algorithms share common characteristics and variables, including mode, key size, weak keys, block size, and rounds. The following sections contain descriptions of the relevant characteristics of the AES cipher.

2.1.  Mode

   NIST has defined 5 modes of operation for AES and other FIPS-approved ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR (Counter). The CBC mode is well-defined and well-understood for symmetric ciphers, and is currently required for all other ESP ciphers. This document specifies the use of the AES cipher in CBC mode within ESP.  This mode requires an Initialization Vector (IV) that is the same size as the block size.  Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's block size.

   The IV is XOR'd with the first plaintext block before it is encrypted.  Then for successive blocks, the previous ciphertext block

   is XOR'd with the current plaintext, before it is encrypted.

   More information on CBC mode can be obtained in [MODES, CRYPTO-S].

   For the use of CBC mode in ESP with 64-bit ciphers, see [CBC].

2.2.  Key Size and Number of Rounds

   AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The default key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits.

   AES uses a different number of rounds for each of the defined key sizes. When a 128-bit key is used, implementations MUST use 10 rounds. When a 192-bit key is used, implementations MUST use 12 rounds. When a 256-bit key is used, implementations MUST use 14 rounds.

 2.3.  Weak Keys

   At the time of writing this document there are no known weak keys for the AES.

   Some cipher algorithms have weak keys or keys that MUST not be used due to their interaction with some aspect of the cipher's definition.

   If weak keys are discovered for the AES, then weak keys SHOULD be checked for and discarded when using manual key management. When using dynamic key management, such as [IKE], weak key checks SHOULD NOT be performed as they are seen as an unnecessary added code complexity that could weaken the intended security [EVALUATION].

2.4.  Block Size and Padding

   The AES uses a block size of sixteen octets (128 bits).

   Padding is required by the AES to maintain a 16-octet (128-bit) blocksize. Padding MUST be added, as specified in [ESP], such that the data to be encrypted (which includes the ESP Pad Length and Next Header fields) has a length that is a multiple of 16 octets.

   Because of the algorithm specific padding requirement, no additional padding is required to ensure that the ciphertext terminates on a 4-octet boundary (i.e., maintaining a 16-octet block size guarantees that the ESP Pad Length and Next Header fields will be right aligned within a 4-octet word). Additional padding MAY be included, as specified in [ESP], as long as the 16-octet blocksize is maintained.

2.5.  Additional Information

   AES was invented by Joan Daemen from Banksys/PWI and Vincent Rijmen from ESAT-COSIC, both in Belgium, and is available world-wide on a royalty-free basis. It is not covered by any patents, and the Rijndael homepage contains the following statement: "Rijndael is available for free. You can use it for whatever purposes you want, irrespective of whether it is accepted as AES or not." AES's description can be found in [AES].  The Rijndael homepage is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.

   The AES homepage, http://www.nist.gov/aes, contains a wealth of information about the AES, including a definitive description of the

   AES algorithm, performance statistics, test vectors and intellectual property information. This site also contains information on how to obtain an AES reference implementation from NIST.

2.6.  Performance

   For a comparison table of the estimated speeds of AES and other cipher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or [PERF-4]. The AES homepage has pointers to other analyses.

3.  ESP Payload

   The ESP payload is made up of the IV followed by raw cipher-text.

   Thus the payload field, as defined in [ESP], is broken down according to the following diagram:

   +---------------+---------------+---------------+---------------+

   |                                                               |

   +               Initialization Vector (16 octets)               +

   |                                                               |

   +---------------+---------------+---------------+---------------+

   |                                                               |

   ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~

   |                                                               |

   +---------------------------------------------------------------+

   The IV field MUST be the same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random, and MUST be unpredictable.

   Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit.

   To avoid CBC encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs.

3.1.  ESP Algorithmic Interactions

   Currently, there are no known issues regarding interactions between the AES and other aspects of ESP, such as use of certain authentication schemes.

3.2.  Keying Material

   The minimum number of bits sent from the key exchange protocol to the ESP algorithm must be greater than or equal to the key size.

   The cipher's encryption and decryption key is taken from the first <x> bits of the keying material, where <x> represents the required key size.

4.  Test Vectors

   The first 4 test cases test AES-CBC encryption. Each test case includes the key, the plaintext, and the resulting ciphertext.  The values of keys and data are either hexadecimal numbers (prefixed by "0x") or ASCII character strings (surrounded by double quotes). If a value is an ASCII character string, then the AES-CBC computation for the corresponding test case DOES NOT include the trailing null character ('\0') of the string.  The computed cyphertext values are

all hexadecimal numbers.

   The last 4 test cases illustrate sample ESP packets using AES-CBC for encryption.  All data are hexadecimal numbers (not prefixed by "0x").

   These test cases were verified using 2 independent implementations: the NIST AES-CBC reference implementation and an implementation provided by the authors of the Rijndael algorithm (http://csrc.nist.gov/encryption/aes/rijndael/rijndael-unix-refc.tar).

Case #1: Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key

Key : 0x06a9214036b8a15b512e03d534120006

IV : 0x3dafba429d9eb430b422da802c9fac41

Plaintext : "Single block msg"

Ciphertext: 0xe353779c1079aeb82708942dbe77181a

Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key

Key: 0xc286696d887c9aa0611bbb3e2025a45a

IV: 0x562e17996d093d28ddb3ba695a2e6f58

Plaintext : 0x000102030405060708090a0b0c0d0e0f

101112131415161718191a1b1c1d1e1f

Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a

7586602d253cfff91b8266bea6d61ab1

Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key

Key : 0x6c3ea0477630ce21a2ce334aa746c2cd

IV : 0xc782dc4c098c66cbd9cd27d825682c81

Plaintext : "This is a 48-byte message (exactly 3 AES blocks)"

Ciphertext: 0xd0a02b3836451753d493665d33f0e886

2dea54cdb293abc7506939276772f8d5

021c19216bad525c8579695d83ba2684

Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key

Key : 0x56e47a38c5598974bc46903dba290349

IV : 0x8ce82eefbea0da3c44699ed7db51b7d9

Plaintext : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf

b0b1b2b3b4b5b6b7b8b9babbbcbdbebf

c0c1c2c3c4c5c6c7c8c9cacbcccdcecf

d0d1d2d3d4d5d6d7d8d9dadbdcdddedf

Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa

0f3af07a9a31a9c684db207eb0ef8e4e

35907aa632c3ffdf868bb7b29d3d46ad

83ce9f9a102ee99d49a53e87f4c3da55

Case #5: Sample transport-mode ESP packet (ping 192.168.123.100)

Key: 90d382b4 10eeba7a d938c46c ec1a82bf

SPI: 4321

Source address: 192.168.123.3

Destination address: 192.168.123.100

Sequence number: 1

IV: e96e8c08 ab465763 fd098d45 dd3ff893

Original packet:

IP header (20 bytes): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64

Data (64 bytes):

08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617

18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

Augment data with:

Padding: 01020304 05060708 090a0b0c 0d0e

Pad length: 0e

Next header: 01 (ICMP)

Pre-encryption Data with padding, pad length and next header (80 bytes):

08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617

18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

01020304 05060708 090a0b0c 0d0e0e01

Post-encryption packet with SPI, Sequence number, IV:

IP header: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64

SPI/Seq #: 00004321 00000001

IV: e96e8c08 ab465763 fd098d45 dd3ff893

Encrypted Data (80 bytes):

f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856

a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a

a269add0 47ad2d59 13ac19b7 cfbad4a6

Case #6: Sample transport-mode ESP packet

         (ping -p 77 -s 20 192.168.123.100)

Key: 90d382b4 10eeba7a d938c46c ec1a82bf

SPI: 4321

Source address: 192.168.123.3

Destination address: 192.168.123.100

Sequence number: 8

IV: 69d08df7 d203329d b093fc49 24e5bd80

Original packet:

IP header (20 bytes): 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64

Data (28 bytes):

0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

Augment data with:

Padding: 0102

Pad length: 02

Next header: 01 (ICMP)

Pre-encryption Data with padding, pad length and next header (32 bytes):

0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

Post-encryption packet with SPI, Sequence number, IV:

IP header: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64

SPI/Seq #: 00004321 00000008

IV: 69d08df7 d203329d b093fc49 24e5bd80

Encrypted Data (32 bytes):

f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75

Case #7: Sample tunnel-mode ESP packet (ping 192.168.123.200)

Key: 01234567 89abcdef 01234567 89abcdef

SPI: 8765

Source address: 192.168.123.3

Destination address: 192.168.123.200

Sequence number: 2

IV: f4e76524 4f6407ad f13dc138 0f673f37

Original packet:

IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8

Data (64 bytes):

08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617

18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

Augment data with:

Padding: 01020304 05060708 090a

Pad length: 0a

Next header: 04 (IP-in-IP)

Pre-encryption Data with original IP header, padding, pad length and

                         next header (96 bytes):

45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d

02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223

24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04

Post-encryption packet with SPI, Sequence number, IV:

IP header: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8

SPI/Seq #: 00008765 00000002

IV: f4e76524 4f6407ad f13dc138 0f673f37

Encrypted Data (96 bytes):

773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8

e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5

c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d

Case #8: Sample tunnel-mode ESP packet

         (ping -p ff -s 40 192.168.123.200)

Key: 01234567 89abcdef 01234567 89abcdef

SPI: 8765

Source address: 192.168.123.3

Destination address: 192.168.123.200

Sequence number: 5

IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22

Original packet:

IP header (20 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8

Data (48 bytes):

0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff

ffffffff ffffffff ffffffff ffffffff

Augment data with:

Padding: 01020304 05060708 090a

Pad length: 0a

Next header: 04 (IP-in-IP)

Pre-encryption Data with original IP header, padding, pad length and

                         next header (80 bytes):

45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d

a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

ffffffff 01020304 05060708 090a0a04

Post-encryption packet with SPI, Sequence number, IV:

IP header: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8

SPI/Seq #: 00008765 00000005

IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22

Encrypted Data (80 bytes):

15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5

0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3

d2726d9b 5ef6affc 6d17a0de cbb13892

5.  IKE Interactions

5.1.  Phase 1 Identifier

   For Phase 1 negotiations, IANA has assigned an Encryption Algorithm ID of 7 for AES-CBC.

5.2.  Phase 2 Identifier

   For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 12 for ESP_AES.

5.3.  Key Length Attribute

   Since the AES allows variable key lengths, the Key Length attribute MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 exchange [DOI].

5.4.  Hash Algorithm Considerations

   A companion competition, to select the successor to SHA-1, the widely-used hash algorithm, recently concluded. The resulting hashes, called SHA-256, SHA-384 and SHA-512 [SHA2-1, SHA2-2] are capable of producing output of three different lengths (256, 384 and 512 bits), sufficient for the generation (within IKE) and authentication (within ESP) of the three AES key sizes (128, 192 and 256 bits).

   However, HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently considered of sufficient strength to serve both as IKE generators of 128-bit AES keys and as ESP authenticators for AES encryption using 128-bit keys.

6.  Security Considerations

   Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well. However, a key size of 128 bits is considered secure for the foreseeable future.

   For more information regarding the necessary use of random IV values, see [CRYPTO-B].

   For further security considerations, the reader is encouraged to read

   [AES].

7.  IANA Considerations

   IANA has assigned Encryption Algorithm ID 7 to AES-CBC.

   IANA has assigned ESP Transform Identifier 12 to ESP_AES.

8.  Intellectual Property Rights Statement

   The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights

might or might not be available; neither does it represent that it has made any effort to identify any such rights.  Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice

this standard. Please address the information to the IETF Executive Director.

9. References

9.1. Normative References

[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001.

http://csrc.nist.gov/publications/fips/fips197/fips-197.{ps,pdf}

[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

9.2. Informative References

[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997.

http://www.research.att.com/~smb/papers/probtxt.pdf

[CRYPTO-S] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.

[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic Evaluation of IPsec," Counterpane Internet Security,Inc., January 2000.

http://www.counterpane.com/ipsec.pdf

[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001.

http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

[PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C Implementations of Round1 Candidate Algorithms for the Advanced Encryption Standard."

http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf

[PERF-2] Lipmaa, Helger, "AES/Rijndael: speed."

http://www.tcs.hut.fi/~helger/aes/rijndael.html

[PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J.Foti and E. Roback, "Status Report on the First Round of the Development of the Advanced Encryption Standard."

http://csrc.nist.gov/encryption/aes/round1/r1report.pdf

[PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the

AES Submissions."

http://www.counterpane.com/aes-performance.pdf

[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[ROAD] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

[SHA2-1] NIST, FIPS PUB 180-2 "Specifications for the Secure Hash Standard," August 2002.

http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf

[SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512."

http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf

10. Acknowledgments

Portions of this text, as well as its general structure, were unabashedly lifted from [CBC].

The authors want to thank Hilarie Orman for providing expert advice (and a sanity check) on key sizes, requirements for Diffie-Hellman groups, and IKE interactions. We also thank Scott Fluhrer for his helpful comments and recommendations.

11. Authors' Addresses

Sheila Frankel

NIST

820 West Diamond Ave.

Room 677

Gaithersburg, MD 20899

Phone: +1 (301) 975-3297

EMail: sheila.frankel@nist.gov

Scott Kelly

Airespace

110 Nortech Pkwy

San Jose CA 95134

Phone: +1 408 635 2000

EMail: scott@hyperthought.com

Rob Glenn

NIST

820 West Diamond Ave.

Room 605

Gaithersburg, MD 20899

Phone: +1 (301) 975-3667

EMail: rob.glenn@nist.gov

2. Алгоритм шифрования AES-CBC и его применение с IPSec

Аннотация

Этот документ описывает применение алгоритма Усовершенствованного Стандарта Шифрования (AES) в режиме построения цепочек шифрованных блоков (CBC), с конечным вектором инициализации (IV), в качестве механизма сокрытия в поле данных безопасной инкапсуляции протокола IPSec (ESP).

Содержание

1. Вступление

1.1 Перечисление требований

2. Алгоритм шифрования AES

2.1 Режимы

2.2 Длина ключа и количество циклов

2.3 Нестойкие ключи

2.4 Размер блоков и поля

2.5 Дополнительные сведения

2.6 Производительность

3. Поле данных безопасной инкапсуляции

3.1 Принцип действия ESP

3.2 Создание ключей

4. Экспериментальные векторы

5. Взаимодействия IKE

5.1 Определитель 1 фазы

5.2 Определитель 2 фазы

5.3 Атрибут длины ключа

5.4 Анализ алгоритма хэширования

6. Положения по безопасности

7. Назначения IANA

8. Формулировка прав интеллектуальной собственности

9. Ссылки

9.1 Нормативные источники

9.2 Информативные базы

10. Благодарности

11. Адреса авторов

1. Вступление

Для замены уязвимого DES алгоритма более совершенным механизмом, NIST (Национальный Институт Стандартов и Технологии), в результате проведения 4-х годичного конкурса, определил новый стандарт AES. Конкурс проводился открыто, с участием всех желающих, и освещался на каждом этапе. AES, некогда известный под названием Рийндейл (далее на англ.Rijndael), был выбран из пяти финалистов.

Выбор пал на AES на основании следующих характеристик:

+безопасность

+ неклассифицированность

+ открытый код

+ свободное неограниченное распространение

+ возможность работы с блоками размера начиная от 128 бит

+ работа с ключами длинной 128, 192 и 256 бит

+ эффективные вычислительная способность и использование памяти для разнообразного программного и аппаратного обеспечения, включая смарт-карты

+ гибкость, простота и лёгкость внедрения

AES избран предпочтительным в качестве стандарта шифрования для государственных структур. Ожидается, что возможностей алгоритма будет достаточно для защиты нестандартной (неклассифицированной) государственной информации по крайней мере до наступления следующего века. Так же предполагается, что он будет широко использован в бизнес кругах и в деятельности финансовых институтов.

Цель группы разработчиков IPSec — IETF — адаптировать AES повсеместно как основной IPSec ESP шифр и закрепить за ним статус обязательного метода шифрования во всех совместимых с IPSec протоколах.

В конце данного документа приводятся особенности использования AES в протоколе IPSec ESP. За дополнительной информацией о том, как различные составляющие ESP взаимодополняют друг друга для обеспечения сервисов безопасности, следует обратиться к [ARCH], [ESP] и [ROAD] документации.

1.1 Перечисление требований

Выражения «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «БУДЕТ», «НЕ БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДОВАНО», «МОЖЕТ» и «ОПЦИОНАЛЬНО», употребляемые в данном документе необходимо интерпретировать в соответствии с указаниями [RFC-2119].

2. Алгоритм шифрования AES

Все симметричные алгоритмы блочного шифрования обладают схожими характеристиками и переменными, включая режим, длину ключа, уязвимые ключи, размер блока и количество прогонов (циклов). Данный раздел содержит описания соответствующих характеристик, касающихся алгоритма шифрования AES.

2.1 Режимы

NIST определил 5 режимов работы для AES и других одобренных FIPS шифров [РЕЖИМЫ]:

CBC (цепочки шифро-блоков), ECB (электронная кодовая книга), CFB (обратная связь по битам шифртекста), OFB (обратная связь вывода) и CTR (шифрование со счётчиком). Метод CBC детально описан и хорошо изучен для симметричных шифров, и на данный момент является обязательны к применению для всех ESP шифров. Данный документ описывает применение AES в режиме CBC внутри ESP. Этот режим требует наличия вектора инициализации (IV), аналогичного блоку данных размера. Использование случайно сгенерированного IV предотвращает возможность получения идентичных шифртекстов (зашифрованных данных) из пакетов, имеющих одинаковые данные, входящие в начало блока алгоритма шифра.

До того, как IV будет зашифрован, над ним производят операцию «исключающего или» (XOR) с помощью первого блока незашифрованного текста. Затем, для успешно преобразованных блоков, до шифрования предшествующего блока шифртекста, он подвергается операции «исключающего или» с текущим шифртекстом.

Более подробную информацию о режиме CBC можно получить в [РЕЖИМЫ, CRYPTO-S].

О возможности использования режима CBC в ESP с 64битными шифрами, ознакомьтесь с [CBC].

2.2 Длина ключа и количество циклов

AES поддерживает три длины ключей: 128, 192 и 256 бит. По умолчанию используется 128-битный ключ, и все реализации протокола ДОЛЖНЫ поддерживать эту длину, но МОГУТ поддерживать и длины в 192 и 256 бит.

Для каждой предопределённой длины ключа AES использует разное количество циклов. При 128битном, должно использоваться 10 циклов прогона, для 192 битного — 12 циклов, ключ в 256 бит прогоняется 14 раз.

2.3 Нестойкие ключи

На момент написания данного документа ни одного потенциально нестойкого ключа для алгоритма известно не было.

Некоторые алгоритмы шифрования имеют так называемые слабые ключи или ключи, которые не ДОЛЖНЫ быть использованы по причине их взаимодействия с некоторыми аспектами шифроопределения (раскрытия).

В случае, если указанные ключи будут найдены для AES, их СЛЕДУЕТ немедля проверить и запретить для неавтоматического подбора. При использовании динамической автогенерации ключей, такой как, например, [IKE], проверка на нестойкость указанных ключей проводиться не будет, т.к. данные ключи отображаются как ненужное дополнительное кодовое множество, являющееся потенциальной угрозой для заданного уровня безопасности [ОЦЕНКА].

2.4 Размер блоков и пэддинг

AES использует 16 октетов (128 бит) для формирования блока.

Пэддинг (дополнение до полного блока) в AES алгоритме необходим для поддержания 16-октетного (128битной длины) размера блока. Как указано в [ESP], для того, чтобы информацию подвергнуть шифрованию (включая длину полей ESP и следующего заголовка), размер блока должен быть кратен 16 октетам, при этом используется пэддинг.

В силу особенностей алгоритма, для проверки шифртекста на окончание 4-х октетным блоком никакого дополнительного пэддинга не предусмотрено (т.е. соблюдение 16 октетного размера блока гарантирует, что длины полей ESP и следующего заголовка всегда будут выровнены 4 октетным словом). Для поддержки ширины поля в максимально 16 октетов, возможен дополнительный пэддинг (как указано в [ESP]).

2.5 Дополнительные сведения

AES был разработан Джоан Демен из Banksys/PWI и Винсен Римен из ESAT-COSIC, оба родом из Бельгии. Алгоритм доступен без ограничений и распространяется на бесплатной основе. Данный стандарт не защищён патентами, а домашняя страничка Rijndael гласит следующее: «Rijndael распространяется свободно. Вы можете использовать его для любых целей, неважно, будет ли это расцениваться как AES стандарт или нет.». Описание AES вы можете найти в [AES]. Домашняя страница Rijndael находится по адресу: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.

Домашняя страница AES, http://www.nist.gov/aes, содержит обширную информацию о AES, включая конечную информацию о самом алгоритме, статистике производительности, экспериментальных векторах и соответствующих авторских прав. Данный сайт так же содержит контактную информацию НИСТ, занимающейся поддержкой реализаций AES.

2.6 Производительность

Для ознакомления с таблицей сравнения расчётных скоростей AES и других алгоритмов шифрования, обратитесь к [PERF-1], [PERF-2], [PERF-3] или [PERF-4]. На странице AES так же доступны ссылки на другие анализы.

3. Поле данных безопасной инкапсуляции (ПДБИ)

ПДБИ состоит из IV вектора и следующего за ним неформатированного шифртекста.

Таким образом, поле данных инкапсуляции, как определено в [ESP], можно разбить как указано на следующей диаграмме:

Поле IV ДОЖНО быть одинакового размера с блоком используемого шифроалгоритма. IV должен быть выбран случайным образом и не должен быть предсказуемым.

При включении в каждую датаграмму IV поля, обеспечивается возможность дешифрации каждой полученной датаграммы, даже если при этом некоторые из них были утрачены (или отброшены) при передаче или подверглись повторной пересылке.

Чтобы избежать шифрования CBC максимально схожих по содержанию блоков исходных данных в разных пакетах, реализация алгоритма не должна использовать счётчик или другие методы, основанные на дистанции, для IV.

3.1 Принцип действия ESP

На данный момент неизвестно проблематичных случаев, относительно взаимодействия между AES и других аспектов ESP, таких как использование определённых схем аутентификации.

3.2 Создание ключей

Минимальное количество бит посылаемых протоколом обмена ключами в ESP алгоритм должно быть больше или равным размеру ключа.

Ключ шифрования и дешифрования берётся из первых <x> бит ключевого слова (основа для генерации), где <x> - заданная длина ключа.

4. Экспериментальные векторы

Первые приведённые 4 теста проводятся с AES-CBC шифрованием. Каждый случай включает ключ, исходные незашифрованные данные и получаемый в итоге зашифрованный код (шифр). Значения ключей и данных представлены либо в шестнадцатеричном формате (префикс «0x») либо в ASCII формате (выделены двойными кавычками). Если значение выражено в ASCII коде, то AES-CBC вычисления для соответствующего теста НЕ ВКЛЮЧАЮТ хвостовое окончание в виде '\0. Полученный шифртекст приведён в шестнадцатеричном формате.

Нижеприведённые тесты иллюстрируют примеры ESP пакетов, использующие AES-CBC в качестве алгоритма шифрования. Все данные представлены в шестнадцатеричном формате (без префикса «0x»).

Данные эксперименты были проверены 2 независимыми методами: НИСТ AES-CBC и реализацией алгоритма авторов Rijndael.

(http://csrc.nist.gov/encryption/aes/rijndael/rijndael-unix-refc.tar).

Случай #1: Шифруем 16 байт (1 блок) используя AES-CBC со 128-битным ключом.

Ключ: 0x06a9214036b8a15b512e03d534120006

IV : 0x3dafba429d9eb430b422da802c9fac41

Незаш.данные (НД) : "Single block msg"

Шифр: 0xe353779c1079aeb82708942dbe77181a

Случай #2: Шифруем 32 байт (2 блока) используя AES-CBC со 128-битным ключом.

Ключ: 0xc286696d887c9aa0611bbb3e2025a45a

IV: 0x562e17996d093d28ddb3ba695a2e6f58

Незаш.данные (НД) : 0x000102030405060708090a0b0c0d0e0f

101112131415161718191a1b1c1d1e1f

Шифр: 0xd296cd94c2cccf8a3a863028b5e1dc0a

7586602d253cfff91b8266bea6d61ab1

Случай #3: Шифруем 48 байт (3 блока) с помощью AES-CBC со 128-битным ключом.

Ключ : 0x6c3ea0477630ce21a2ce334aa746c2cd

IV : 0xc782dc4c098c66cbd9cd27d825682c81

НД : "This is a 48-byte message (exactly 3 AES blocks)"

Шифр: 0xd0a02b3836451753d493665d33f0e886

2dea54cdb293abc7506939276772f8d5

021c19216bad525c8579695d83ba2684

Случай #4: Шифруем 64 байт (4 блока) используя AES-CBC со 128-битным ключом.

Ключ : 0x56e47a38c5598974bc46903dba290349

IV : 0x8ce82eefbea0da3c44699ed7db51b7d9

НД : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf

b0b1b2b3b4b5b6b7b8b9babbbcbdbebf

c0c1c2c3c4c5c6c7c8c9cacbcccdcecf

d0d1d2d3d4d5d6d7d8d9dadbdcdddedf

Шифр: 0xc30e32ffedc0774e6aff6af0869f71aa

0f3af07a9a31a9c684db207eb0ef8e4e

35907aa632c3ffdf868bb7b29d3d46ad

83ce9f9a102ee99d49a53e87f4c3da55

Случай #5: Пример отправки ESP-пакета (ping 192.168.123.100)

Ключ: 90d382b4 10eeba7a d938c46c ec1a82bf

Индекс параметров безопасности (SPI): 4321

Адрес источника: 192.168.123.3

Адрес получателя: 192.168.123.100

Номер последовательности: 1

IV: e96e8c08 ab465763 fd098d45 dd3ff893

Исходный пакет:

IP заголовок (20 байт): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64

Данные (64 байта):

08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617

18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

Приращаем данные с помощью:

Пэддинг (дополнение): 01020304 05060708 090a0b0c 0d0e

Размер поля: 0e

Следующий заголовок: 01 (ICMP)

Подготовленные для шифрования данные с пэддингом, длинной поля и следующ.заголовком (80 байт):

08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617

18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

01020304 05060708 090a0b0c 0d0e0e01

Зашифрованный пакет с SPI, номером последовательности и IV:

IP заголовок: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64

SPI/Последоват. #: 00004321 00000001

IV: e96e8c08 ab465763 fd098d45 dd3ff893

Готовый код (80 байт):

f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856

a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a

a269add0 47ad2d59 13ac19b7 cfbad4a6

Случай #6: Пример отправки ESP-пакета (ping -p 77 -s 20 192.168.123.100)

Ключ: 90d382b4 10eeba7a d938c46c ec1a82bf

SPI: 4321

Адрес источника: 192.168.123.3

Адрес получателя: 192.168.123.100

Номер последов.: 8

IV: 69d08df7 d203329d b093fc49 24e5bd80

Исходный пакет:

IP заголовок (20 байт): 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64

Данные (28 байт):

0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777

Приращаем данные с помощью:

Пэддинг (дополнение): 0102

Размер поля: 02

Следующий заголовок: 01 (ICMP)

Подготовленные для шифрования данные с пэддингом, длинной поля и следующ.заголовком (32 байта):

0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201

Зашифрованный пакет с SPI, номером последовательности и IV:

IP заголовок: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64

SPI/Послед. #: 00004321 00000008

IV: 69d08df7 d203329d b093fc49 24e5bd80

Шифр (32 байта):

f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75

Случай #7: Пример отправки ESP-пакета (ping 192.168.123.200)

Ключ: 01234567 89abcdef 01234567 89abcdef

SPI: 8765

Адрес источника: 192.168.123.3

Адрес получателя: 192.168.123.200

Номер послед-ти: 2

IV: f4e76524 4f6407ad f13dc138 0f673f37

Исходный пакет:

IP заголовок (20 байт): 45000054 09040000 4001f988 c0a87b03 c0a87bc8

Данные (64 байта):

08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617

18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637

Приращаем данные с помощью:

Пэддинг: 01020304 05060708 090a

Размер поля: 0a

След.заголовок: 04 (IP-in-IP)

Подготовленные для шифрования данные с пэддингом, длинной поля и следующ.заголовком (96 байт):

45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d

02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223

24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04

Зашифрованный пакет с SPI, номером последовательности и IV:

IP заголовок: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8

SPI/Послед. #: 00008765 00000002

IV: f4e76524 4f6407ad f13dc138 0f673f37

Шифр (96 байт):

773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8

e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5

c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d

Случай #8: Пример отправки ESP-пакета (ping -p ff -s 40 192.168.123.200)

Ключ: 01234567 89abcdef 01234567 89abcdef

SPI: 8765

Адрес источника: 192.168.123.3

Адрес получателя: 192.168.123.200

Номер послед-ти: 5

IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22

Исходный пакет:

IP заголовок (20 байт): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8

Данные (48 байт):

0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff

ffffffff ffffffff ffffffff ffffffff

Приращаем данные с помощью:

Пэддинг: 01020304 05060708 090a

Размер поля: 0a

След.заголовок: 04 (IP-in-IP)

Подготовленные для шифрования данные с пэддингом, длинной поля и следующ.заголовком (80 байт):

45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d

a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

ffffffff 01020304 05060708 090a0a04

Зашифрованный пакет с SPI, номером последовательности и IV:

IP заголовок: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8

SPI/Послед. #: 00008765 00000005

IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22

Шифр (80 байт):

15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5

0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3

d2726d9b 5ef6affc 6d17a0de cbb13892

5.  Взаимодействия IKE

5.1 Определитель 1 фазы

Для 1-й фазы для AES-CBC IANA назначила 7-й идентификатор шифрования.

5.2. Определитель 2 фазы

Для 2-й фазы для ESP-AES IANA назначила 12-й идентификатор преобразования ESP.

5.3 Атрибут длины ключа

Поскольку AES допускает переменные длины ключа, атрибут Длина Ключа ДОЛЖЕН быть установлен как в обмене первой фазы [IKE] так и второй [DOI].

5.4 Анализ алгоритма хеширования

Недавно был проведён конкурс на замену широкораспространённого алгоритма хеширования SHA-1, входящим в комплекс вычислений алгоритма AES. Утверждённые хеши, под названиями SHA-256, 384 и 512 [SHA2-1, SHA2-2], могут выдавать три длины (256, 384 и 512 бит), достаточные для генерации (в области IKE) и аутентификации (в области ESP) трёх AES ключей (128, 192 и 256 бит).

Не смотря на это, HMAC-SHA-1 [HMAC-SHA] и HMAC-MD5 [HMAC-MD5] на данный момент до сих пор считаются приемлемыми по силе стойкости в качестве генераторов IKE 128-битных AES ключей и ESP аутентификаторов для шифрования по AES с 128-битными ключами.

6. Меры безопасности

Реализации протокола рассчитаны на использования максимально возможных для них длин ключей, с учётом производительности на определённых устройствах и в определённой программной среде. Помните, что шифрование сказывается на скоростях передачи в обоих направлениях: как в сторону клиента, так и на сервер. Однако считается, что должного уровня защиты 128-битного ключа хватит на обозримое будущее.

Дополнительную информацию, касаемо необходимости использования случайных значений IV можно почерпнуть из [CRYPTO-B].

7. Назначения IANA

IANA назначила 7-й идентификационный номер алгоритма шифрования для AES-CBC.

IANA назначила 12-й номер преобразования ESP алгоритма для ESP-AES.

8. Формулировка прав интеллектуальной собственности

IETF не занимает ничью позицию относительно правомерности или сферы интеллектуальной собственности или других прав, которые могут быть истребованы в отношении реализации или использования технологии, описанной в данном документе или выходящих за его рамки, для которой любая лицензия на таких правах может быть доступна или не доступна; так же этим не подтверждается, что были предприняты какие-либо попытки идентифицировать указанные права. Информацию о процедурах IETF на правах документации стандартов отслеживания и стандартов относящихся к данной теме можно найти в BCP-11.

Копии заявлений на права предоставлены в свободном доступе, а любые заверения лицензий для возможности подобной публикации, или результат попытки получения генеральных лицензий или разрешений к использованию указанных проприетарных прав разработчиками или пользователями этих спецификаций, могут быть получены в IETF Секретариате.

IETF приглашает всех заинтересованных лиц (организации) вносить предложения по правам, патентам или патентным заявкам, или другим проприетарным правам, которые могут охватывать технологию и требуются для практического применения рассмотренного стандарта. Пожалуйста, высылайте информацию исполнительному директору IETF.

9. Ссылки

9.1 Нормативные источники

[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001.

http://csrc.nist.gov/publications/fips/fips197/fips-197.{ps,pdf}

[CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

9.2. Информативные базы

[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997.

http://www.research.att.com/~smb/papers/probtxt.pdf

[CRYPTO-S] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995, ISBN 0-471-12845-7.

[DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[EVALUATION] Ferguson, N. and B. Schneier, "A Cryptographic Evaluation of IPsec," Counterpane Internet Security,Inc., January 2000.

http://www.counterpane.com/ipsec.pdf

[HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.

[HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.

[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques," NIST Special Publication 800-38A, December 2001.

http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

[PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C Implementations of Round1 Candidate Algorithms for the Advanced Encryption Standard."

http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf

[PERF-2] Lipmaa, Helger, "AES/Rijndael: speed."

http://www.tcs.hut.fi/~helger/aes/rijndael.html

[PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J.Foti and E. Roback, "Status Report on the First Round of the Development of the Advanced Encryption Standard."

http://csrc.nist.gov/encryption/aes/round1/r1report.pdf

[PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the

AES Submissions."

http://www.counterpane.com/aes-performance.pdf

[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[ROAD] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

[SHA2-1] NIST, FIPS PUB 180-2 "Specifications for the Secure Hash Standard," August 2002.

http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf

[SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512."

http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf

10. Благодарности

Часть текста как и его структура были открыто позаимствованы из [CBC].

Авторы хотят поблагодарить Hilarie Orman за предоставление экспертного мнения (и проверки целостности) по размерам ключей, требованиям

для множеств Diffie-Hellman и операциям IKE. Мы так же благодарим Scott Fluhrer за его ценные советы и рекомендации.

11. Адреса авторов

Sheila Frankel

NIST

820 West Diamond Ave.

Room 677

Gaithersburg, MD 20899

Phone: +1 (301) 975-3297

EMail: sheila.frankel@nist.gov

Scott Kelly

Airespace

110 Nortech Pkwy

San Jose CA 95134

Phone: +1 408 635 2000

EMail: scott@hyperthought.com

Rob Glenn

NIST

820 West Diamond Ave.

Room 605

Gaithersburg, MD 20899

Phone: +1 (301) 975-3667

EMail: rob.glenn@nist.gov

24049

23066

3.Wi-Fi Protected Access 2 (WPA2) Overview (Обзор защищённого доступа Wi-Fi версии протокола 2)

Introduction

The original IEEE 802.11 standard provided the following set of security features to secure wireless LAN communication:

1.       Two different authentication methods: Open system and shared key

2.       The Wired Equivalent Privacy (WEP) encryption algorithm

3.       An Integrity Check Value (ICV), encrypted with WEP, which provided data integrity

Обзор защищённого доступа Wi-Fi версии протокола 2

Введение

Изначально стандартом IEEE 802.11 был представлен следующий набор функциональных возможностей, обеспечивающий защиту передачи данных в среде ЛВС:

1.       Два различных метода аутентификации: Открытый ключ и совместный доступ

2.       Алгоритм шифрования «Эквивалент Проводной Защищенности» WEP

3.       Проверка значения целостности (ICV), зашифрованная с помощью WEP протокола

Over time, these security features proved to be insufficient to protect wireless LAN communication in common scenarios. To address the security issues of the original IEEE 802.11 standard, the following additional technologies are used:

·       The IEEE 802.1X Port-Based Network Access Control standard is an optional method for authenticating 802.11 wireless clients. IEEE 802.1X provides per-user identification and authentication, extended authentication methods, and, depending on the authentication method, encryption key management dynamic, per-station or per-session key management and rekeying.

Со временем этой функциональности стало недостаточно для защиты передачи данных по наиболее распространённым сценариям. Для соответствия требованиям стандарта IEEE 802.11, были введены следующие дополнения:

·       Опциональным методом аутентификации 802.11 беспроводных клиентов назначен стандарт IEEE 802.1X защиты сети на основе физических портов. Этот стандарт позволяет проводить идентификацию и аутентификацию каждого пользователя, а так же расширенную аутентификацию, и в зависимости от метода используемого при аутентификации: динамическое управление ключами шифрования, управление на основе по-станционного или по-сессионного ключа шифрования и его переназначения.

·       Wi-Fi Protected Access (WPA) is an interim standard adopted by the Wi-Fi Alliance to provide more secure encryption and data integrity while the IEEE 802.11i standard was being ratified. WPA supports authentication through 802.1X (known as WPA Enterprise) or with a preshared key (known as WPA Personal), a new encryption algorithm known as the Temporal Key Integrity Protocol (TKIP), and a new integrity algorithm known as Michael. WPA is a subset of the 802.11i specification.

·       Объединением Wi-Fi Alliance был введён стандарт защищённого Wi-Fi Доступа (WPA) первой ревизии, для предоставления временной защиты шифрования и верификации целостности данных более высокого уровня, до тех пор, пока не будет ратифицирован стандарт IEEE 802.11i. WPA поддерживает аутентификацию с помощью 802.1Х (известный как промышленный стандарт WPA) или с разделяемым ключом (персональный WPA) — тем самым, появился новый протокол шифрования TKIP (протокол краткосрочной целостности ключей) и новый алгоритм проверки целостности данных, известный под названием Michael. WPA является подуровнем спецификации 802.11i.

The IEEE 802.11i standard formally replaces Wired Equivalent Privacy (WEP) and the other security features of the original IEEE 802.11 standard. WPA2 is a product certification available through the Wi-Fi Alliance that certifies wireless equipment as being compatible with the 802.11i standard. The goal of WPA2 certification is to support the additional mandatory security features of the 802.11i standard that are not already included for products that support WPA. Like WPA, WPA2 offers both Enterprise and Personal modes of operation.

Microsoft has released WPA2/WPS IE Update, a free download that updates the wireless client components in Windows XP with Service Pack 2 to support WPA2. This article describes the features of WPA2 security  and the support for WPA2 included with the WPA2/WPS IE Update.

Отныне стандарт IEEE 802.11i официально заменил WEP и другие способы защиты первоначального стандарта IEEE 802.11.Эталоном сертификации беспроводного оборудования Wi-Fi Объединения стал стандарт WPA2 — как совместимый с 802.11i. Цель сертификации по WPA2 — поддерживать обязательные функции защиты доступа по реквизитам стандарта 802.11i, который ещё не включён в продукты, поддерживающие WPA. Как и WPA, WPA2 представлен в двух версиях: промышленный (коммерческий) и персональный режимы.

Для поддержки WPA2 фирма Microsoft выпустила бесплатное обновление WPA2/WPS для клиента Internet Explorer (IE), входящее в состав SP2. Данная статья раскрывает особенности безопасности стандарта WPA2 и его поддержку в обновлении к IE.

Features of WPA2 Security

The following features of WPA2 security are supported in the WPA2/WPS IE Update:

WPA2 authentication

For WPA2 Enterprise, WPA2 requires authentication in two phases; the first is an open system authentication and the second uses 802.1X and an Extensible Authentication Protocol (EAP) authentication method. For environments without a Remote Authentication Dial-In User Service (RADIUS) infrastructure such as small office/home office (SOHO) networks, WPA2 Personal supports the use of a preshared key (PSK).

WPA2 key management

Like WPA, WPA2 requires the determination of a mutual pairwise master key (PMK) based on the EAP or PSK authentication processes and the calculation of pairwise transient keys through a 4-way handshake.

For more information, see Wi-Fi Protected Access Data Encryption and Integrity.

Особенности безопасности WPA2.

Следующие функции безопасности WPA были включены в WPA2/WPS IE обновление:

WPA2 аутентификация

Для промышленного варианта WPA2 используется аутентификация в два этапа; аутентификация открытых систем и аутентификация с использованием 802.1Х и протокола EAP (Расширенный протокол аутентификации). Для сред без поддержки протокола RADIUS (служба дистанционной аутентификации пользователей по коммутируемым линиям), таких, например, как SOHO (малый бизнес/домашняя сеть), используется разделяемый ключ доступа (PSK) — WPA2 в персональном режиме.

Управление ключами WPA2

Как и WPA, WPA2 требует определения соответствующего парного мастер-ключа (PMK) базирующегося на исполнении EAP или PSK процесса аутентификации и вычисления временных парных ключей с использованием «4хстороннего рукопожатия» (4-хкратный обмен сервисными пакетами для установления соединения).

За дополнительной информацией, обратитесь к статье «Шифрование данных и проверка целостности по стандарту WPA».

Advanced Encryption Standard

WPA2 requires support for the Advanced Encryption Standard (AES) using the Counter Mode-Cipher Block Chaining (CBC)-Message Authentication Code (MAC) Protocol (CCMP). AES Counter Mode is a block cipher that encrypts 128-bit blocks of data at a time with a 128-bit encryption key. The CBC-MAC algorithm produces a message integrity code (MIC) that provides data origin authentication and data integrity for the wireless frame. A Packet Number field included in the WPA2-protected wireless frame and incorporated into the encryption and MIC calculations provides replay protection. AES encryption meets the Federal Information Processing Standard (FIPS) 140-2 requirement.

AES (усовершенствованный стандарт шифрования)

WPA2 требует наличия поддержки AES, при этом используется режим построения цепочек шифрованных блоков (cbc) — протокола кода сообщения аутентификации (MAC CCMP). AES режима счётчика представляет собой блок шифров который кодирует 128битные блоки данных в один момент времени с помощью 128битного ключа шифрования. Алгоритм CBC MAC далее генерирует поле целостности данных (MIC), позволяющее проводить аутентификацию источника данных и проверку их целостности во фрейме беспроводной сети. Для предотвращения повторов используется поле Номер Пакета, входящее в защищённый с помощью WPA2 фрейм и включённое в процессы шифрования и вычисления MIC. Стандарт шифрования AES отвечает требованиям FIPS 140-2.

Additional Features of WPA2 for Fast Roaming

When a wireless client authenticates using 802.1X, there are a series of messages sent between the wireless client and the wireless access point (AP) to exchange credentials. This message exchange introduces a delay in the connection process. When a wireless client roams from one wireless AP to another, the delay to perform 802.1X authentication can cause especially for time-dependent traffic such as voice or video-based data streams. To minimize the delay associated with roaming to another wireless AP, WPA2 wireless equipment can optionally support PMK caching and preauthentication.

Дополнительные особенности WPA2 для быстрого переключения между точками (роуминг)

Для обмена реквизитами между беспроводным клиентом и точкой доступа (AP), при генерации процесса аутентификации по протоколу 802.1Х, между ними происходит обмен сервисным пакетами (сообщениями). Этот сервисный обмен создаёт некоторую задержку перед началом передачи данных. В случае обмена голосовых или видеоданных, которые весьма требовательны к скорейшей пересылке, такое блуждание пакетов от беспроводного клиента то к одной, то к другой точке доступа для прохождения 802.1Х аутентификации, может повлечь за собой серьёзные задержки. Чтобы избежать этого, оборудование стандарта WPA2 опционально поддерживает PMK кэширование и преаутентификацию.

PMK Caching

As a wireless client roams from one wireless AP to another, it must perform a full 802.1X authentication with each wireless AP. WPA2 allows the wireless client and the wireless AP to cache the results of a full 802.1X authentication so that if a client roams back to a wireless AP with which it has previously authenticated, the wireless client needs to perform only the 4-way handshake and determine new pairwise transient keys. In the Association Request frame, the wireless client includes a PMK identifier that was determined during the initial authentication and stored with both the wireless client and wireless AP's PMK cache entries. PMK cache entries are stored for a finite amount of time, as configured on the wireless client and the wireless AP.

To make the transition faster for wireless networking infrastructures that use a switch that acts as the 802.1X authenticator, the WPA2/WPS IE Update calculates the PMK identifier value so that the PMK as determined by the 802.1X authentication with the switch can be reused when roaming between wireless APs that are attached to the same switch. This practice is known as opportunistic PMK caching.

For information about controlling PMK caching behavior with registry values, see WPA2/WPS IE Update.

PMK кэширование.

По мере того, как происходит обмен данных между клиентом и точками доступа, первый должен постоянно проводить полноценную 802.1X аутентификацию с каждой из точек. В случае WPA2, возможно упростить и ускорить процесс, за счёт того, что при повторной аутентификации клиента с точкой, к которой он был однажды подключён, ему необходимо провести лишь «4-хкратное (стороннее) рукопожатие» и определить новые временные парные ключи. Идентификатор PMK, определяемый при первоначальном процессе аутентификации, сохраняется как самим клиентом, так и точкой доступа в кэше ключей, и клиент его включает во фрейм Соответствия Запросов. Кэш PMK ключей имеет ограниченное время хранения записей в соответствии с параметрами беспроводного клиента и точки доступа.

Для обеспечения скорейшего перехода внутри беспроводной инфраструктуры, базирующейся на коммутаторе, аутентифицирующем по протоколу 802.1Х, обновление WPA2/WPS IE вычисляет значение идентификатора PMK так, чтобы этот PMK, определённый при 802.1Х-аутентификации с коммутатором, мог быть использован вновь в случае соединения с точками доступа, подключёнными к этому же коммутатору. Данная процедура известна как гибкая система PMK кэширования.

Для получения информации управления PMK кэшированием со значениями реестра, обратитесь к описанию WPA2/WPS IE обновления.

Preauthentication

With preauthentication, a WPA2 wireless client can optionally perform 802.1X authentications with other wireless APs within its range, while connected to its current wireless AP. The wireless client sends preauthentication traffic to the additional wireless AP over its existing wireless connection. After preauthenticating with a wireless AP and storing the PMK and its associated information in the PMK cache, a wireless client that connects to a wireless AP with which it has preauthenticated needs to perform only the 4-way handshake.

WPA2 clients that support preauthentication can only preauthenticate with wireless APs that advertise their preauthentication capability in Beacon and Probe Response frames.

For information about controlling preauthentication behavior with registry values, see WPA2/WPS IE Update.

Предварительная аутентификации

Для осуществления альтернативной 802.1Х аутентификации с другой точкой доступа в зоне её действия, беспроводной клиент может провести предварительную аутентификацию, при том, что подключение к текущей беспроводной точке доступа (AP) не разрывается. Для этого клиент посылает запрос на указанную аутентификацию к другой AP, используя существующее беспроводное соединение. После удачной аутентификации и сохранения соответствующего PMK ключа в кэше, клиенту для установления соединения с выбранной точкой требуется провести лишь «4-хкратное рукопожатие».

Клиенты стандарта WPA2, поддерживающие преаутентификацию, могут осуществлять данную операцию лишь при условии, что выбранные точки доступа оповещают о своей возможности преаутентификации фреймами Сигнального и Пробного Ответа.

Для получения информации об управлении процессом преаутентификации со значениями реестра, обратитесь к описанию WPA2/WPS IE обновления.

Supporting a Mixture of WPA2, WPA and WEP Wireless Clients

WPA2 certified wireless equipment is also compatible with WPA and WEP. You can have a mixture or WPA2, WPA, and WEP wireless devices operating in the same environment.

Одновременная поддержка WPA2, WPA и WEP-беспроводных клиентов

Сертифицированное по стандарту WPA2 оборудование так же обратно совместимо с WPA и WEP стандартами. Вы можете одновременно использовать беспроводное оборудование с поддержкой WPA2, WPA или WEP режимов в одной рабочей среде.

Changes Required to Support WPA2

WPA2 support requires changes to the following:

·       Wireless APs

·       Wireless network adapters

·       Wireless client software

Changes to wireless APs

With WPA, wireless network devices could be upgraded through a firmware update because the WPA security features leveraged the existing computational facilities designed for WEP. With WPA2, however, a wireless AP that does not have the computational facilities to perform the more complex calculations for AES CCMP cannot be upgraded through a firmware update and must be replaced. These types of wireless APs are typically older wireless APs manufactured before inclusion of support for the 802.11g standard. Newer wireless APs, such as those that support the 802.11g standard, might be upgradeable with a firmware update.

Изменения, которые необходимо вносить для поддержки WPA2

Для полноценной поддержки WPA2 необходимо подвергать замене:

5. Беспроводные точки доступа

6. Адаптеры беспроводного доступа

7. Клиентское ПО для адаптеров

Изменения, затрагивающие беспроводные точки доступа

Устройства с поддержкой WPA могут быть обновлены с помощью программного микрокода, поскольку особенности безопасности WPA повысили уровень существующих вычислительных требований, которые были разработаны для WEP. Однако, для обеспечения функциональности WPA2, AP, не располагающая возможностями для осуществления более сложных вычислений - AES CCMP, не может быть усовершенствована обычным программным обновлением и должна быть заменена. Обычно это более старые точки доступа, выпущенные до включения поддержки стандарта 802.11g. Более новые APs, могут быть обновлены новым микрокодом.

Check with your wireless AP vendor documentation or Web site to determine if your wireless APs require replacement or a firmware update to support WPA2. If only a firmware update is needed, obtain the update from your wireless AP vendor and install it on your wireless APs.

For information about wireless APs that have been WPA2 certified, see the Wi-Fi Alliance Certified Products Listing.

Changes to wireless network adapters

Like wireless APs, whether you must replace wireless network adapters depends on whether they have the computational facilities to perform AES CCMP. Check with your wireless network adapter vendor documentation or Web site to determine if your wireless network adapters require replacement or a firmware update in order to support WPA2. If only a firmware update is needed, obtain the update from your wireless adapter vendor and install it on your wireless network adapters.

For wireless clients running Windows XP with Service Pack 2, you must obtain an updated network adapter driver that supports WPA2. The updated network adapter driver must be able to pass the adapter's WPA2 capabilities to Windows XP Wireless Auto Configuration.

For information about wireless network adapters that have been WPA2 certified, see the Wi-Fi Alliance Certified Products Listing

Чтобы определить, поддерживает ли ваша AP WPA2 с помощью прошивки более новым ПО, обратитесь к документации или веб-странице производителя. В случае, если возможно обновление микрокода, без замены устройства, получите необходимое ПО от разработчика и обновите с его помощью точку доступа.

Чтобы узнать, какие из беспроводных точек доступа были сертифицированы по WPA2 стандарту, обратитесь к списку продуктов сертифицированных WA.

Изменения, касающиеся клиентских беспроводных адаптеров.

Как и в случае с AP, необходимо выяснить, достаточно ли вычислительных возможностей у вашего адаптера для AES CCMP. Процедура аналогична вышеуказанному методу для беспроводных точек доступа.

Для беспроводных клиентов, установленных на платформе MS WinXP c SP2 (кумулятивный пакет обновлений, выпуск 2), скачайте обновлённый драйвер беспроводной сетевой платы с поддержкой WPA2. Обновлённый драйвер должен сообщить необходимый WPA2-функционал для автонастройки беспроводной среды WinXP.

Чтобы узнать, какие из беспроводных адаптеров были сертифицированы по WPA2 стандарту, обратитесь к списку продуктов сертифицированных WA.

Changes to wireless client programs

Wireless client software must be updated to allow for the configuration of WPA2 authentication options. The WPA2/WPS IE Update for computers running Windows XP with SP2 includes support for WPA2 and modifies the following

·       The Choose a wireless network dialog box

·       The Association tab for the properties of a wireless network.

When you are connected to a WPA2-capable wireless network, the type of network is displayed as WPA2 in the Choose a wireless network dialog box. The following figure shows an example.

Изменения, касающиеся клиентского ПО

Указанное ПО должно быть обновлено для поддержки настройки необходимых параметров WPA2 аутентификации. Обновление WPA2/WPS IE для компьютеров с предустановленным ПО WinXP SP2, включает в себя поддержку WPA2 и добавляет следующие возможности:

• Диалоговое окно «Выбора беспроводной сети»

• Закладка «связи» для свойств беспроводных сетей

При подключении к сети с поддержкой WPA2, тип сети отображается как WPA2 в диалоговом окне «выбора беспроводной сети». Нижеследующий снимок экрана содержит пример.

On the Association tab for the properties of a wireless network, the Network Authentication drop-down box has the additional options: WPA2 (for WPA2 Enterprise) and WPA2-PSK (for WPA2 Personal). These options will be present only if the wireless network adapter and its driver support WPA2.

В закладке «связи», внутри свойств беспроводной сети, при выводе выпадающего списка «сетевая аутентификация», добавляется новая опция: WPA2 (для промышленного WPA2) и WPA2-PSK (для персональной версии). Эти опции будут отображены только если беспроводной адаптер и его драйвер поддерживают WPA2.

9729

10230

4.Cryptographic Design Vulnerabilities (Слабые места криптографических систем)

Bruce Schneier (Counterpane Systems)

Strong cryptography is very powerful when it is done right, but it is not a panacea. Focusing on cryptographic algorithms while ignoring other aspects of security is like defending your house not by building a fence a round it, but by putting an immense stake in the ground and hoping that your adversary runs right into it.

Popular magazines often describe cryptography products in terms of algorithms and key lengths. These security techniques make good headlines. They can be explained in a few words and they’re easy to compare with one another. We’ve seen statements like “128-bit keys mean strong security, while 40-bit keys are weak” or “triple-DES is much stronger than single DES” or even “2,048-bit RSA is better than 1,024-bit RSA.”

U n f o rt u n a t e l y, cryptography isn’t so simple: Longer keys do not guarantee more security.

C o m p a re a cryptographic algorithm to the lock on your front door. Most door locks have four metal pins, each of which can be in one of 10 positions. A metal key sets the pins in a particular configuration. If the key aligns them all correctly, the lock opens. So there are only 10,000 possible keys, and a burglar willing to try all 10,000 is guaranteed to break into your house.

But an improved lock with 10 pins—making 10 billion possible keys—probably won’t make your house m o re secure. Burglars don’t try every possible key (the equivalent of a bru t e - f o rce attack); most are n ’t clever enough to pick the lock (the equivalent of a cryptographic attack). No, they smash windows, kick in doors, disguise themselves as police, and rob keyholders at gunpoint. One ring of art thieves in California defeated home security systems by taking a chainsaw to the house walls. Better locks can’t prevent these attacks.

Слабые места криптографических систем

Брюс Шнайер

Мощные, грамотно построенные криптографические системы способны на многое, но нельзя считать их панацеей. Пользователи, уделяющие слишком много внимания алгоритмам шифрования в ущерб другим методам обеспечения безопасности, похожи на людей, которые вместо того, чтобы обнести свои владения высоким забором, перегораживают дорогу массивными воротами, нисколько не задумываясь о том, что злоумышленникам не составит труда сделать шаг в сторону и обойти сей "неприступный бастион".

В популярных журналах классификация продуктов шифрования проводится, как правило, по алгоритму и длине ключа. Обзоры печатаются под броскими заголовками. Описание особенностей того или иного продукта и его сравнение с конкурирующими предложениями легко укладывается буквально в несколько слов. Наверняка каждому из вас доводилось встречать утверждения типа: "128-разрядные ключи обеспечивают надежную защиту, в то время как 40-разрядные вскрываются довольно легко", "алгоритм triple-DES гораздо надежнее в сравнении с обычным алгоритмом DES" или даже "шифрование RSA с 2048-разрядным ключом лучше RSA с 1024-разрядным ключом".

Однако в криптографии не все так просто: более длинные ключи отнюдь не гарантируют повышенной безопасности.

Давайте попробуем сравнить алгоритмы шифрования с замком от входной двери. Во многих дверных замках установлено четыре металлических шипа, каждый из которых может находиться в одном из десяти положений. Если ключ соответствует конфигурации замка, запор открывается. Таким образом, конструкция каждого однотипного замка предусматривает 10 000 различных комбинаций. Следовательно, для того, чтобы проникнуть в дом, взломщик должен перепробовать до 10 000 ключей.

Замки усовершенствованной конструкции имеют уже 10 шипов (10 млрд. комбинаций), но это вовсе не значит, что за безопасность своего жилища теперь можно не беспокоиться. Совершенно очевидно, что взломщики не станут последовательно подбирать все возможные ключи (это было бы слишком примитивно): они достаточно умны, для того чтобы проникнуть в дом иным способом (в данном случае напрашивается аналогия с криптографической атакой). Гораздо проще и эффективнее разбить окно, выломать дверь или переодеться в форму полицейского и приставить ствол пистолета к голове ничего не подозревающего хозяина. Один из грабителей в Калифорнии, недолго думая, распилил стену дома бензопилой. Понятно, что от таких действий не спасут даже самые лучшие замки.

Strong cryptography is very powerful when it is done right, but it is not a panacea. Focusing on cry p t o g r a p h i c algorithms while ignoring other aspects of security is like defending your house not by building a fence a round it, but by putting an immense stake in the g round and hoping that your adversary runs right into it. Smart attackers will just go around the algorithms.

Counterpane Systems has spent years designing, analyzing, and breaking cryptographic systems. While we do research on published algorithms and pro t o c o l s, most of our work examines actual products. We ’ v e designed and analyzed systems that protect privacy, e n s u re confidentiality, provide fairness, and facilitate commerce. We’ve worked with software, stand-alone h a rd w a re, and everything in between. We’ve bro k e n our share of algorithms, but we can almost always fin d attacks that bypass the algorithms altogether.

We don’t have to try every possible key or even fin d flaws in the algorithms. We exploit errors in design, errors in implementation, and errors in installation. Sometimes we invent a new trick to break a system, but most of the time we exploit the same old mistakes that designers make over and over again. This art i c l e conveys some of the lessons we’ve learn e d .

Мощные, грамотно построенные криптографические системы способны на многое, но нельзя считать их панацеей от всех бед. Пользователи, уделяющие слишком много внимания алгоритмам шифрования в ущерб другим методам обеспечения безопасности, похожи на людей, которые вместо того, чтобы обнести свои владения высоким забором, перегораживают дорогу массивными воротами, нисколько не задумываясь о том, что злоумышленникам не составит труда сделать шаг в сторону и обойти сей "неприступный бастион". Квалифицированные взломщики просочатся даже через самую незаметную брешь.

Компания Counterpane Systems вот уже в течение многих лет занимается созданием, анализом и взломом систем шифрования. Мы исследуем алгоритмы или протоколы, спецификации которых опубликованы в открытой печати; большая часть работы связана с изучением особенностей конкретных продуктов. Нам довелось проектировать и анализировать средства, защищающие частную тайну, гарантирующие конфиденциальность, отстаивающие справедливость и обеспечивающие функционирование систем электронной торговли. Мы работали с самыми различными программными пакетами, автономными аппаратными средствами и аппаратно-программными решения. Нам прекрасно известны слабые места алгоритмов шифрования, но почти всегда мы находили более элегантные способы обхода систем безопасности.

ATTACKS AGAINST DESIGN

A cryptographic system can only be as strong as the encryption algorithms, digital signature algorithms, one-way hash functions, and message authentication codes it relies on. In other words, break any of them, and you’ve broken the system. And just as it’s possible to build a weak structure using strong materials, it’s possible to build a weak cryptographic system using strong algorithms and pro t o c o l s .

A great many systems “void the warranty” of their cryptography by using it improperly: They fail to check the size of values, reuse random parameters that should never be reused, and so on. Encryption algorithms don’t necessarily provide data integrity. Key exchange protocols don’t necessarily ensure that both parties receive the same key.

Some—not all—systems that use related cryptographic keys can be broken, even though each individual key is secure. Security is a lot more than plugging in an algorithm and expecting the system to work. Even good engineers, well-known companies, and lots of e ff o rt are no guarantee of robust implementation. Cryptographic weaknesses discovered in the Code Division Multiple Access (CDMA) and Global System for Mobile (GSM) communications cellular encryption algorithms and in the Microsoft Point-to-Point Tunneling Protocol (PPTP) illustrate that. In PPTP, for example, we found the strong RC4 algorithm used in a mode that almost completely negated its security.

Random-number generators are another place w h e re cryptographic systems often break. Good random-number generators are hard to design because their security often depends on the particulars of the h a rd w a re and software .1 , 2 Their cryptography may be strong, but if the random-number generator pro d u c e s weak keys, the system is much easier to break. Some products use secure random-number generators, but they don’t use enough randomness to make the cryptography secure. One of the most surprising results in this area is that specific random-number generators may be secure for one purpose but insecure for another.

Other attacks look at interactions between individually secure cryptographic pro t o c o l s .3 Given a s e c u re protocol, it is sometimes possible to build another secure protocol that will break the first if both a re used with the same keys on the same device. Given the proliferation of diverse security standards using the same infrastru c t u re, this kind of interaction failure is potentially very dangerous .

Атаки на архитектуру

Криптографическая система не может быть надежнее использованных в ней отдельных алгоритмов шифрования. Иными словами, для того чтобы преодолеть систему защиты, достаточно взломать любой из ее компонентов. Использование хороших строительных материалов еще не является гарантией прочности здания. Так и криптографическая система, построенная на основе мощных алгоритмов и протоколов, тоже может оказаться слабой.

Многие системы "теряют гарантию" безопасности, если используются неправильно. Скажем, проверка допустимости значений переменных не выполняется, "случайные" параметры используются многократно, что совершенно недопустимо. Алгоритмы шифрования необязательно обеспечивают целостность данных. Протоколы обмена ключами необязательно гарантируют, что обе стороны получат один и тот же ключ.

Некоторые системы шифрования, использующие связанные ключи, могут быть взломаны, даже если каждый ключ в отдельности надежен. Чтобы обеспечить безопасность, недостаточно просто реализовать алгоритм и ждать, что все будет работать. Даже наличие квалифицированных инженеров, помощь известных компаний и упорный труд не могут гарантировать абсолютной надежности. Бреши, обнаруженные в алгоритмах шифрования систем сотовой связи стандартов CDMA и GSM, а также в протоколе Microsoft Point-to-Point Tunneling Protocol (PPTP), наглядно это иллюстрируют. К примеру, в достаточно надежном алгоритме RC4, на котором построен протокол PPTP, нам удалось обнаружить режим, который делал защиту абсолютно прозрачной.

Еще одно слабое место криптографических средств - генераторы случайных чисел. Разработать хороший генератор случайных чисел непросто, поскольку он часто зависит от особенностей аппаратного и программного обеспечения [1,2]. Сама система шифрования может быть выполнена на высоком уровне, но если генератор случайных чисел выдает легко угадываемые ключи, то все оставшиеся барьеры преодолеваются без особого труда. В ряде продуктов используются генераторы случайных чисел, вырабатывающие ключи, в которых прослеживается определенная закономерность. В таких случаях о безопасности говорить не приходится. Интересно, что применение одного и того же генератора в некоторых областях обеспечивает требуемую степень безопасности, а в других - нет.

Еще одно возможное слабое место - взаимодействие между по отдельности безопасными протоколами шифрования [3]. Почти для каждого безопасного протокола, как правило, можно найти другой, не менее надежный, который сведет на нет все достоинства первого, если они оба используют одинаковые ключи на одном и том же устройстве. Если различные стандарты защиты применяются в одной среде, недостаточно четкое взаимодействие между ними зачастую может привести к весьма нежелательным последствиям.

ATTACKS AGAINST IMPLEMENTATION

Many systems fail because of mistakes in implementation. Some systems don’t ensure that plaintext is destroyed after it’s encrypted. Other systems use t e m p o r a ry files to protect against data loss during a system crash or use virtual memory to increase the available memory. These features can accidentally leave plaintext lying around on the hard drive.

Buffer overflows, secrets not erased pro p e r l y, and poor error checking and recovery are all examples of implementation weaknesses that could be exploitable. In extreme cases, the OS can leave the keys on the hard drive. One product by a large software company uses a special window for password input. The password remains in the window’s memory even after it is closed. It doesn’t matter how good that pro d u c t ’s cryptography is; we broke it through the user interface.

Other systems fall to more subtle vulnerabilities. Sometimes the same data is encrypted with two different keys, one strong and one weak. Other systems use master keys and then one-time session keys. Still others can be broken using partial information about different keys. And some systems use inadequate pro t e c t i o n mechanisms for the master keys, mistakenly relying on the security of the session keys. It’s vital to secure all possible ways to learn a key, not just the most obvious ones.

E l e c t ronic commerce systems often make implementation trade-offs to enhance usability. There are many subtle vulnerabilities here, when designers don’t think through the security implications of their tradeoffs. Doing account reconciliation only once per day, for example, might be easier, but what kind of damage can an attacker do in a few hours? Can audit mechanisms be flooded to hide the identity of an attacker? Some systems re c o rd compromised keys on hotlists; attacks against these hotlists can be very fruitful. Other systems can be broken through re p l a y attacks—by reusing old messages or parts of old messages—to fool various part i e s .

Systems that allow old keys to be recovered in an e m e rg e n c y, key escro w systems, provide another are a to attack.4Good cryptographic systems are designed so that the keys exist for as short a period of time as possible; key re c o v e ry often negates any security benefit by forcing keys to exist long after they are useful. Furthermore, key-recovery databases themselves become sources of vulnerability and have to be designed and implemented secure l y. In some published systems, flaws in the key-re c o v e ry database could allow criminals to commit fraud and then frame legitimate users.

Атаки на конкретные реализации

Многие системы подводят из-за ошибок в реализации. Некоторые продукты не гарантируют, что, зашифровав текст, они уничтожат оригинал. В других для предупреждения потери информации в случае системного сбоя используются временные файлы, а доступная оперативная память расширяется за счет памяти виртуальной; в этом случае на жестком диске могут оставаться отдельные фрагменты незашифрованного текста.

Переполнение буферов, не стертая до конца секретная информация, недостаточно надежная система обнаружения и восстановления после ошибок - все это примеры брешей в конкретных реализациях, через которые очень часто и проникают злоумышленники. В наиболее вопиющих случаях операционная система даже оставляет ключи на жестком диске. В одном из продуктов крупной софтверной компании ввод пароля осуществлялся через специальное окно. При этом пароль сохранялся в буфере окна и после его закрытия. Проводить дальнейшие исследования защищенности системы уже не имело смысла. Мы проникли в нее через пользовательский интерфейс.

Слабые стороны других продуктов не так явно бросались в глаза. Иногда одни и те же данные шифровались при помощи двух ключей: первый из них был надежным, а второй подбирался достаточно легко; но при этом эксперименты с уже подобранным ключом помогал подобрать и другой. В других системах применялись мастер-ключи и ключи "на один сеанс"; причем безопасности главного ключа уделялось недостаточное внимание, а основные надежды возлагались на одноразовые ключи. Для создания по-настоящему надежной системы безопасности необходимо полностью исключить возможность анализа строения ключей, а не ограничиваться лишь самыми очевидными мерами предосторожности.

Создатели систем электронной коммерции часто вынуждены идти на компромисс ради расширения функциональности. И поскольку разработчики предпочитают жертвовать безопасностью, в защите то и дело появляются дыры. Сверка учетных записей, к примеру, может проводиться только раз в день, но за несколько часов взломщик способен нанести поистине колоссальный ущерб! Перегрузка процедуры идентификации может привести к тому, что личность атакующего не будет распознана. Некоторые системы заносят сомнительные ключи в "черные списки"; получение доступа к этим спискам существенно облегчает задачу взломщика. Многие системы защиты преодолеваются после повторных атак и использования старых сообщений или их частей, сбивающих систему с толку.

Потенциальная опасность заложена в возможности восстановления ранее использовавшихся ключей в системах с расщеплением [4]. В хороших криптографических системах срок жизни ключей ограничивается максимально коротким промежутком времени. Процедура восстановления позволяет продлить жизнь ключа уже после того, как от него отказались. Используемые для восстановления ключей базы данных сами по себе являются источником опасности, и их архитектура должна быть выверена с особой тщательностью. В ряде случаев бреши в них позволяли взломщикам маскироваться под легальных пользователей.

ATTACKS AGAINST HARDWARE

Some systems, particularly commerce systems, re l y on “secure perimeter” tamper- resistant hard w a re such as smart cards, electronic wallets, and dongles. These systems are based on the notion that the secrets inside the secure perimeter cannot be manipulated by those not authorized access. While hard w a re security is an i m p o rtant component in many secure systems, it is p rudent to distrust systems whose security rests solely on assumptions about tamper re s i s t a n c e .

Most tamper- resistance techniques do not work, and tools for defeating tamper resistance are getting better all the time.5,6 When designing systems that use tamper resistance, it is important to build in complementary security mechanisms, just in case the tamper resistance fails. It is also important to make sure that the value of the data being protected is much less than the estimated cost to defeat the tamper resistance. The re q u i red physical protections for a system designed to meter public-transportation access, for example, are much less than those for a system designed to trade financial port f o l i o s .

The “timing attack” made a big press splash in 1995: RSA private keys could be re c o v e red by measuring the relative times cryptographic operations took.7 The attack has been successfully implemented against smart c a rds and other security tokens and against electro n i c c o m m e rce servers across the Internet. Cry p t o g r a p h e r s have generalized these methods to include attacks on a system by measuring power consumption, radiation emissions, and other “side channels,” and they have implemented them against a variety of public-key and symmetric algorithms in “secure” tokens.3

Related re s e a rch has looked at fault analysis, a method that deliberately introduces faults into cry p t o g r a p h i c p rocessors in order to determine secret keys. These attacks are almost biological in nature; they look at the c ryptographic system as a complex object that re s p o n d s to stimuli, and not just as a mathematical equation. The e ffects of this kind of attack can be devastating.

Атаки на оборудование

Некоторые системы (чаще всего коммерческого назначения) имеют так называемое "кольцо безопасности", состоящее из аппаратных средств повышенной устойчивостью к взломам (смарт-карт, электронных бумажников, электронных ключей и т.д.) [5,6]. Создатели подобных систем исходят из предположения, что архитектура системы внутри этого кольца надежно защищена от несанкционированного доступа. Надежность оборудования - очень важная составляющая комплексных систем безопасности, но не стоит полностью доверять решениям, защищающим только от воровства и неумелого обращения.

Большинство подобных технологий на практике не работают, а инструменты для их взлома непрерывно совершенствуются [5,6]. При проектировании подобных систем очень важно не забывать о дополнительных механизмах защиты, которые должны срабатывать, если взломщикам удастся преодолеть первые оборонительные редуты. Нужно постараться максимально осложнить задачу противника и сделать ее решение невыгодным с экономической точки зрения. Стоимость защищаемых данных должна быть значительно ниже затрат на разрушение системы безопасности. Ценность электронного проездного не может идти ни в какое сравнение со стоимостью портфеля ценных бумаг. Исходя из этого и следует проектировать средства защиты.

В 1995 году значительно возросло число "атак по расписанию": выяснилось, что секретные ключи RSA можно восстанавливать, измеряя временные интервалы между операциями шифрования [7]. Был зарегистрирован ряд случаев успешного взлома смарт-карт, а также серверов электронной коммерции в Internet. Обнаружилось, что атаки строились на основе измерения потребляемой мощности, анализа электромагнитного излучения и других побочных источников информации. Специалистам по криптографии удалось по этим признакам реконструировать логику многих систем с открытыми ключами, продемонстрировав их ненадежность.

Большую популярность приобрел метод анализа сбоев, позволяющий находить слабые места криптопроцессоров и восстанавливать секретные ключи. Подобные методы по своему духу скорее биологические. Криптографические системы в этом случае рассматриваются как сложные объекты, которые реагируют на внешние раздражители. Их нельзя четко описать с помощью математических уравнений, но последствия таких атак разрушительны.

ATTACKS AGAINST TRUST MODELS

We direct many of our more interesting attacks against the underlying trust model of the system: who or what in the system is trusted, in what way, and to what extent. Simple systems—like hard-drive encry ption programs or telephone privacy pro d u c t s — h a v e simple trust models. Complex systems—like electronic commerce systems or multiuser e-mail security p rograms—have complex (and subtle) tru s t models involving many part i e s .

An e-mail program might use uncrackable c ryptography for the messages, but unless the keys are cert i fied by a trusted source (and unless that cert i fication can be verified in real time) the system is still vulnerable. Some commerce systems can be broken by a merchant and a customer colluding, or by two diff e rent customers colluding. Other systems make implicit assumptions about security infrastru c t u res, but don’t bother to check that those assumptions are actually true. If the trust model isn’t documented, then an engineer can unknowingly change it in product development and compromise security.

Many software systems make poor trust assumptions about the computers they run on; they assume the desktop is secure. These programs can often be b roken by Trojan horse software that sniffs passwords, reads plaintext, or otherwise circumvents security measures. Systems working across computer networks have to worry about security flaws re s u l ting from the network protocols. Computers that are attached to the Internet can also be vulnerable.

Again, the cryptography may be irrelevant if it can be circumvented through network insecurity. And no s o f t w a re is secure against reverse-engineering. Often, a system will be designed with one trust model in mind and implemented with another. Decisions made in the design process might be completely ignored when it comes time to sell it to customers. A system that is s e c u re when the operators are trusted and the computers are completely under the control of the company using the system may not be secure when the operators are temps hired at just over minimum wage and the computers are untru s t e d .

Good trust models work even if some of the tru s t assumptions turn out to be wro n g .

Атаки на модели доверительных отношений

Многие интересные способы преодоления защитных рубежей связаны с моделями доверительных отношений внутри системы. Прежде всего, следует выявить связи между отдельными компонентами системы, уяснить ограничения и механизм реализации схемы доверительных отношений. Простые системы (средства шифрования телефонных переговоров и информации на жестких дисках) используют элементарные доверительные модели. Комплексные системы (средства электронной торговли или средства защиты многопользовательских пакетов электронной почты) построены на основе сложных (и гораздо более надежных) моделей доверительных отношений, описывающих взаимосвязи множества элементов.

В программе электронной почты может использоваться супернадежный алгоритм шифрования сообщений, но если ключи не сертифицированы источником, заслуживающим доверия, и сертификация эта не может быть подтверждена в реальном времени, безопасность системы остается под вопросом. Некоторые торговые системы могут быть вскрыты по соглашению продавца с покупателем или в результате объединенных усилий нескольких клиентов. В других системах предусмотрено наличие средств обеспечения безопасности, но качество этих средств никто никогда не проверял. Если модель доверительных отношений не документирована, то в процессе развертывания в продукт можно случайно внести какие-либо недопустимые изменения, после чего стройность системы безопасности будет нарушена.

Многие программные пакеты слишком доверяются защищенности аппаратных средств. Предполагается, что компьютер абсолютно безопасен. Рано или поздно в такую программу проникает "троянский конь", который подбирает пароли, считывает незашифрованный текст или каким-то иным образом вмешивается в работу системы защиты. Разработчикам систем, функционирующих в компьютерных сетях, следует побеспокоиться о безопасности сетевых протоколов. Уязвимость компьютеров, подключенных к Internet, многократно возрастает.

Система шифрования, которая преодолевается "со стороны сети", никуда не годится. Не существует программ, безопасность которых выстояла после того, как противнику удалось применить обратное проектирование. Очень часто система проектируется в расчете на одну модель доверительных отношений, а в практической реализации фигурирует совсем другая. Принятые в процессе проектирования решения полностью игнорируются после передачи готового продукта пользователям. Система, которая абсолютно безопасна, когда ее операторы заслуживают доверия, а доступ к компьютерам полностью контролируется, теряет все свои преимущества, если обязанности операторов выполняют низкооплачиваемые работники, нанятые на короткий срок, а физический контроль за компьютерами утрачен.

Впрочем, хорошие модели доверительных отношений продолжают работать даже в том случае, если отдельные компоненты подводят.

ATTACKS ON USERS

Even when a system is secure if used pro p e r l y, its users can subvert its security by accident—especially if the system isn’t designed very well.8 The classic example of this is the user who gives a password to coworkers so they can fix some problem when he’s out of the office. So-called “social-engineering” attacks can often yield better results than months of cry p t a n a l y s i s .9

Users may not re p o rt missing smart cards for a few days in case they are just misplaced. They may not carefully check the name on a digital cert i ficate. They may reuse their secure passwords on other, insecure systems. They may not change their software’s default weak security settings. Good system design can’t fix all these social problems, but it can help avoid many of them.

Many systems break because they rely on usergenerated passwords. Left to themselves, people don’t choose strong passwords. If they’re forced to use s t rong passwords, they can’t remember them. If the p a s s w o rd becomes a key, it’s usually much easier— and faster—to guess the password than it is to acquire the key by bru t e - f o rce attack; we’ve seen elaborate security systems fail in this way.

Some user interfaces make the problem even worse: limiting the passwords to eight characters, convert i n g e v e rything to lower case, and so forth. Even passphrases can be weak: Searching through 40-character phrases is often much easier than searc h i n g t h rough 64-bit random keys. Sometimes key-re c o ve ry systems circumvent strong session keys by using weak passwords for key re c o v e ry. The desire for failsafe redundancy opens up a back door for attackers.

Атаки на пользователей

Даже если система гарантирует надежную защиту при правильной эксплуатации, пользователи могут случайно нарушить ее, особенно если система спроектирована недостаточно хорошо [8]. Классическим примером является сотрудник, предоставляющий свой пароль коллегам с тем, чтобы они имели возможность решать неотложные задачи во время его отсутствия. Атака с учетом "человеческого фактора" зачастую оказывается куда более эффективной, чем месяцы кропотливого анализа алгоритмов [9].

Пользователи могут в течение нескольких дней не сообщать об утере смарт-карты. Они не уделяют требуемого внимания проверке электронной подписи. Секретные пароли порой повторно используются в несекретных системах. Клиенты даже не пытаются ликвидировать слабые места в системе безопасности. Конечно, даже хорошие системы не в состоянии ликвидировать последствия причин социального свойства, но они могут свести их к минимуму.

Многие продукты взламываются потому, что их защита построена на основе паролей, генерируемых пользователями. Предоставленные сами себе люди не задумываются о том, как выбрать необычную последовательность символов. Ведь пароль, который невозможно подобрать, не так просто запомнить. Если в качестве секретного ключа применяется такой пароль, то подобрать его, как правило, удается гораздо проще и быстрее, чем используя метод грубой силы.

Многие пользовательские интерфейсы еще больше облегчают задачу взломщика, ограничивая длину пароля 8 знаками, преобразуя вводимую последовательность в символы нижнего регистра и т.д. Даже пароли-фразы не обеспечивают требуемой степени безопасности. Злоумышленнику намного легче подобрать фразу из 40 букв, чем перебирать все возможные последовательности 64-разрядных случайных ключей. Иногда защита, в которой применяются очень надежный механизм ключи сеансов, разрушается из-за использования слабых паролей, предназначенных для восстановления ключей. Желание облегчить восстановление системы после сбоя фактически открывает перед атакующими черный ход.

ATTACKS AGAINST FAILURE RECOVERY

Strong systems are designed to keep small security b reaks from becoming big ones. Recovering the key to one file should not allow the attacker to read every file on the hard drive. Being able to forge money is a serious crime; being able to write a general pro g r a m that allows anyone to forge money can destroy a curren c y. A hacker who reverse-engineers a smart card should only learn the secrets in that smart card, not i n f o rmation that will help break other smart cards in the system. In a multiuser system, knowing one pers o n ’s secrets shouldn’t compromise everyone else’s .

Many systems have a default to insecure mode. If the security feature doesn’t work, most people just t u rn it off and finish their business. This makes denial of - s e rvice attacks very effective: If the online cre d i t c a rd verification system is down, merchants will default to the less-secure paper system.

S i m i l a r l y, it is sometimes possible to mount a v e r - sion ro l l b a c k attack against a system after it has been revised to fix a security problem: The need for backward compatibility allows an attacker to force the protocol into an older, insecure, version.

Other systems have no ability to recover from disaster. If the security breaks, there ’s no way to fix it. For e l e c t ronic commerce systems, which could have millions of users, this can be particularly damaging. Such systems should plan to respond to attacks and to upgrade security without having to shut the system down.

The phrase “and then the company shuts down” is never something you want to put in your business plan. Good system design considers what will happen when an attack occurs and works out ways to contain the damage and recover from the attack.

Атака на средства восстановления после сбоев

Разработчики надежных систем не в состоянии заделать в заборе безопасности все мельчайшие щели, но по крайней мере зияющие дыры они ликвидируют. Восстановление ключа к одному файлу не позволит взломщику считать всю информацию, находящуюся на жестком диске. Изготовление фальшивых денег - очень серьезное преступление, ведь обладатель технологии печатания денег может уничтожить национальную валюту. Хакер, взламывающий смарт-карту, изучает секреты данного конкретного устройства, а не всех остальных смарт-карт, входящих в систему. В многопользовательских системах знание секретов одного человека не должно открывать доступа к информации других.

Многие системы по умолчанию устанавливаются в режим с отключенными средствами безопасности. Если система защиты "заедает", пользователь просто отключает ее и продолжает заниматься своим делом. Такое поведение делает особенно эффективными атаки типа denial-of-service ("отказ в обслуживании"). Если онлайновая система авторизации кредитных карт отключена, продавец вынужден довольствоваться значительно менее надежной бумажной технологией.

Иногда у взломщиков появляется возможность воспользоваться обратной совместимостью различных версий программного обеспечения. Как правило, в каждом новом варианте продукта разработчики стараются устранить бреши, имевшиеся в старом. Но требование обратной совместимости позволяет атакующему применять протокол старой, незащищенной версии.

Некоторые системы не имеют средств восстановления. Если защита разрушена, вернуть программу в работоспособное состояние не представляется возможным. Выход из строя системы электронной торговли, к которой обращаются миллионы клиентов, грозит обернуться катастрофой. Поэтому подобные системы должны иметь средства организации противодействия атакующим и поддерживать возможность обновления системы безопасности без остановки программы.

Хорошо продуманная система сама знает, как лучше противостоять атаке и что следует делать для устранения повреждений и оперативного восстановления работоспособности.

ATTACKS AGAINST CRYPTOGRAPHY

Sometimes, products even get the cry p t o g r a p h y w rong. Some rely on pro p r i e t a ry encryption algorithms. Invariably, these algorithms are weak. Cryptographers have surprising success breaking published encryption algorithms; their track re c o rd against pro p r i e t a ry ones is even better. Keeping the algorithm secret isn’t much of an impediment to analysis anyway, because it only takes a couple of days to reverse-engineer the cryptographic algorithm fro m executable code.

The S/MIME 2 e-mail standard took a re l a t i v e l y s t rong design and implemented it with a weak cry ptographic algorithm. The system for GSM encry p t i o n took a weak algorithm and made it weaker. And many systems just use keys that are too short .1 0

T h e re are many other common cryptographic mistakes: implementations that repeat “unique” random values, digital-signature algorithms that don’t properly verify parameters, or hash functions altered to defeat the very properties they’re being used for. Cryptographic protocols are often used in ways unintended by the protocols’ designers. For example, they a re “optimized” in seemingly trivial ways that completely break their security.

Атака на средства шифрования

Иногда слабые места можно найти и непосредственно в системе шифрования. Некоторые продукты создаются на базе не слишком удачных алгоритмов собственной разработки. Как правило, вскрыть известные алгоритмы шифрования удается лишь в исключительных случаях. Если же разработчик делает ставку на собственные методы, шансы взломщиков повышаются многократно. Незнание секрета алгоритма не является особым препятствием. Квалифицированному специалисту достаточно пары дней, чтобы по объектному коду восстановить исходный алгоритм шифрования.

Надежность стандартной для электронной почты архитектуры S/MIME 2 не в состоянии компенсировать слабостей алгоритма шифрования. И без того не слишком надежная защита GSM от слабого алгоритма шифрования проигрывает еще больше. Во многих системах используются слишком короткие ключи [10].

Можно привести множество других примеров ошибок в системах шифрования: программы повторно генерируют "уникальные" случайные значения, алгоритмы цифровой подписи не в состоянии обеспечить контроль за передаваемыми параметрами, хэш-функции открывают то, что должны защищать. В протоколы шифрования вносятся не предусмотренные разработчиками изменения. Пользователи любят "оптимизировать" имеющиеся средства, доводя их до столь примитивного уровня, что вся система защиты рушится, как карточный домик.

PREVENTION VERSUS DETECTION

Most cryptographic systems rely on prevention as their sole means of defense: The cryptography keeps people from cheating, lying, abusing, or whatever. Defense should never be that narrow.

A strong system tries to detect abuse and to contain the effects of any attack. One of our fundamental design principles is that sooner or later every system will be successfully attacked, probably in a completely unexpected way and with unexpected consequences. It is important to be able to detect such an attack and to contain the attack to ensure it does minimal damage.

M o re import a n t l y, once the attack is detected, the system needs to re c o v e r. It needs to generate and promulgate a new key pair, update the protocol, invalidate the old one, remove an untrusted node from the system, and so forth. Unfort u n a t e l y, many systems d o n ’t collect enough data to provide an audit trail, or they fail to protect the data against modific a t i o n .

A good audit log has to do much more than detect an attack: It must also be able to produce evidence that can convince a judge and jury of guilt.

Предупреждение, а не выявление

Средства шифрования снижают вероятность того, что пользователи станут жертвами обмана, мошенничества, некорректных действий и т.д. Но архитектуру безопасности нельзя ограничивать столь узкими рамками.

Надежная система должна самостоятельно обнаруживать несанкционированные операции и ликвидировать нежелательные последствия атаки. Один из основных принципов проектирования подобных систем заключается в знании того, что рано или поздно атаки противника увенчаются успехом. Скорее всего, удар будет нанесен в самом неожиданном направлении, с использованием неизвестных разработчикам методов. Очень важно своевременно распознать такое нападение и принять все необходимые меры к тому, чтобы минимизировать ущерб.

Еще важнее как можно быстрее восстановить работоспособность поврежденной в ходе атаки системы. Необходимо сгенерировать новые пары ключей, заменить протокол, прекратить использование раскрытых противником средств, исключить из системы узлы, к которым взломщику удалось получить доступ, и т.д. К сожалению, многие продукты не занимаются сбором нужной информации, не контролируют ситуацию и не в состоянии надежно защитить данные от изменений.

В журнале регистрации должны отражаться все события, позволяющие установить факт нападения. В случае необходимости должны быть представлены неопровержимые доказательства, способные убедить судей и присяжных в виновности злоумышленника.

Security designers occupy what Prussian general Carl von Clausewitz calls “the position of the interior.” A good security product must defend against every possible attack, even attacks that haven’t been invented yet.

Attackers, on the other hand, only need to find one security flaw in order to defeat the system. And they can cheat. They can collude, conspire, and wait for technology to give them additional tools. They can attack the system in ways the system designer never thought of.

Building a secure cryptographic system is easy to do badly and very difficult to do well. Unfort u n a t e l y, most people can’t tell the difference. In other areas of computer science, functionality serves to diff e re n t i a t e the good from the bad: A good codec will work better than a bad one, and a bad codec will look worse in feature-comparison chart s .

Cryptography is diff e rent. Just because an encry ption program works doesn’t mean it is secure. What happens with most products is that someone re a d s Applied Cry p t o g r a p h y, chooses an algorithm and protocol, tests it to make sure it works, and thinks the p roject is done. It’s not.

Functionality does not equal quality, and no amount of beta testing will reveal every security fla w. Too many products are merely buzzword - c o m p l i a n t ; they use secure cryptography but are n ’t secure.

Разработчики систем безопасности должны следовать наставлениям таких авторитетов, как прусский генерал Карл фон Клаузевитц, утверждавший, что хорошие оборонительные средства должны отражать любые удары, даже те, о которых на сегодняшний день еще ничего не известно.

Атакующим, напротив, достаточно найти одну единственную брешь, и вся система защиты будет ликвидирована. Они прибегают к самым разнообразным уловкам. Взломщики не гнушаются участвовать в заговорах, тщательно маскируют свои противоправные действия и готовы в течение достаточно продолжительного времени ждать появления необходимых средств. В их арсенале всегда найдется идея, позволяющая нанести неожиданный для разработчиков удар.

Нет ничего проще, чем оградить свою информацию шатким, непрочным барьером с зияющими в нем дырами. Построить же непроницаемую систему защиты очень сложно. К сожалению, многие пользователи не видят разницы. В других областях анализ функциональных возможностей позволяет без труда отличить качественные продукты от наспех построенных систем. Достоинства хорошего кодека видны невооруженным глазом, плохой же выглядит значительно слабее и не поддерживает тех функций, которые доступны его конкурентам.

В криптографии все по-другому. Тот факт, что программы шифрования работают, еще не позволяет говорить о надежной защите. Как создается большинство продуктов? Разработчики читают Applied Cryptography, выбирают приглянувшийся им алгоритм и протокол, тестируют его, и вот уже проект готов. На самом деле все не так просто.

Функциональность и высокое качество не являются синонимами, и даже бесконечное тестирование не позволяет устранить всех брешей в системе защиты. Нужно хорошо разбираться в тонкостях терминологии: даже продукты, обладающие абсолютно надежными средствами шифрования, зачастую не могут гарантировать пользователям полной безопасности.

Bibliography

1 . P. Gutmann, “Software Generation of Random Numbers

for Cryptographic Purposes,” P roc. 1998 Usenix Security

S y m p., Usenix Assoc., Berkeley, Calif., 1998, pp. 243-257.

2 . J. Kelsey, B. Schneier, and D. Wa g n e r, “Protocol Interactions

and the Chosen Protocol Attack,” Security Pro -

t o c o l s, 5 t h Int’l Wo r k s h o p, Springer- Verlag, New Yo r k ,

1996, pp. 91-104.

3 . C. Hall et al., “Side-Channel Cryptanalysis of Pro d u c t

Ciphers,” P roc. ESORICS 98, Springer- Verlag, New

York, 1998.

4 . H. Abelson et al., “The Risks of Key Recovery, Key

E s c ro w, and Trusted Third - P a rty Encryption,” Wo r l d

Wide Web J., No. 3, 1997, pp. 241-257.

5 . R. Anderson and M. Kuhn, “Tamper Resistance: A Caut

i o n a ry Note,” P roc. Second Usenix Workshop Electro n i c

C o m m e rc e, Usenix Assoc., Berkeley, Calif., 1996, pp. 1-11.

6 . J. McCormac, E u ropean Scrambling Systems, Baylin

Publications, Boulder, Colo., 1997.

7 . P. Kocher, “Timing Attacks on Implementations of Diffie -

Hellman, RSA, DSS, and Other Systems,” P roc. Cry p t o

9 6, Springer- Verlag, New York, 1996, pp. 104-113.

8 . R. Anderson, “Why Cryptosystems Fail,” Comm. ACM,

N o v. 1994, pp. 32-40.

9 . I. Wi n k l e r, Corporate Espionage, Prima Publishing,

Placer County, Calif., 1997.

1 0 . M. Blaze et al., “Minimal Key Lengths for Symmetric

Ciphers to Provide Adequate Commercial Security,” Oct.

1996, ftp://ftp.re s e a rc h . a t t . c o m / d i s t / m a b / k e y l e n g t h . t x t .

Литература

[1] P.Gutmann, "Software Generation of Random Numbers for Cryptographic Purposes", Proc. 1998 Usenic Security Symp., Usenix Assoc., Berkeley, Calif., 1998, pp. 243-257. [2] J.Kelsey, B.Schneier, and D.Wagner, "Protocol Interactions and the Chosen Protocol Attack", Security Protocols, 5th Int'l Workshop, Springer-Verlag, New York, 1996, pp. 91-104. [3] C.Hall et al., "Side-Channel Cryptanalysis of Product Ciphers", Proc. ESORISC 98, Springer-Verlag, New York, 1998. [4] H.Abelson et al., "The Riscs of Key Recovery, Key Escrow and Trusted Third-Party Encryption", World Wide Web J., No. 3, 1997, pp. 241-257. [5] R.Anderson and M.Kuhn, "Tamper Resistance: A Cautionary Note", Proc. Second Usenix Workshop Electronic Commerce, Usenix Assoc., Berkeley, Calif., 1996, pp. 1-11. [6] J.McCormac, European Scrambling Systems, Baylin Publications, Boulder, Colo., 1997. [7] P.Kocher, "Timing Attacks on Implementations of Diffie-Hellman, RSA, DDS and Other Systems", Proc. Crypto 96, Springer-Verlag, New York, 1996, pp. 104-113. [8] R.Anderson, "Why Cryptosystems Fail", Comm. ACM, Nov. 1994, pp. 32-40. [9] I.Winkler Corporate Espionage, Prima Publishing, Placer County, Calif., 1997. [10] M.Blaze et al., "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", Oct. 1996, ftp://ftp.research.att.com/dist/mab/keylength.txt.

B ruce Schneier is president of Counterpane Systems, a cryptography and computer security consulting c o m p a n y. He is the author of Applied Cry p t o g r a p h y (John Wiley & Sons, 1995) and the inventor of the B l o w fish and Tw o fish encryption algorithms. You can subscribe to his free cryptography newsletter at h t t p : / / w w w. c o u n t e r p a n e . c o m .

Об авторе

Брюс Шнайер - президент компании Counterpane Systems, оказывающей консультационные услуги по вопросам шифрования и построения систем компьютерной безопасности. Он является автором книги "Прикладная криптография" (Applied Cryptography, John Wiley & Sons, 1995) и изобретателем алгоритма шифрования Blowfish and Twofish. На его бесплатный бюллетень последних новостей из области криптографии можно подписаться на Web-сервере http://www.counterpane.com.

The Global Public Key Infrastructure: Terms and Concepts

A n d rew Csinger, Xcert Software Keng Siau, University of Nebraska, Lincoln

In one sense, you’re not a citizen of your c o u n t ry unless you can prove your nationality. And until you’re part of the global public key infrastructure (GPKI), you’re not an authentic citizen of the global elect ronic community.

Глобальная инфраструктура открытых ключей

Эндрю Ксингер, Кенг Сяу

До тех пор, пока вы не вольетесь в глобальную инфраструктуру систем шифрования с открытым ключом (GPKI, global public key infrastructure), вас не будут считать полноправным членом глобального электронного сообщества.

Public and private keys

Public key cryptography involves two keys—a private key and a public key—that a re mathematically related so that a message encrypted with one can be decry p t e d only with the other. It is extremely diff icult—if not impossible—to determine the value of one key by examining the other.

The public key is often called the e n c ryption key. To send a message to Jack—so that only Jack can read it—Jill would use Jack’s public key. Jack would then use his private key to decrypt the message. We re Jack to send a re p l y, he would use Jill’s public key, and Jill would use her private key to decrypt it.

In this way, public key cry p t o g r a p h y helps ensure privacy.

Открытые и секретные ключи

В алгоритмах шифрования с открытым ключом используются две разновидности ключей -открытые и секретные. Между ними существует определенная математическая зависимость, выражающаяся в том, что сообщение, зашифрованное одним ключом, может быть декодировано только при наличии другого. Определить значение одного ключа, зная другой, крайне сложно (а порой и просто невозможно).

Открытые ключи часто являются шифрующими. Чтобы отправить Джеку сообщение (при условии, что прочитать его сможет только Джек), Джилл должна иметь под рукой открытый ключ Джека. Получив сообщение, Джек может расшифровать его при помощи своего секретного ключа. В свою очередь Джек, отправляя электронное послание, шифрует его с помощью открытого ключа Джилл, а Джилл декодирует поступившую информацию своим секретным ключом.

Таким образом, шифрование с открытым ключом гарантирует конфиденциальность.

Digests

Senders can also digitally sign their messages so that recipients have more assurance that the message is authentic. First, a user creates a unique message fingerprint— or d i g e s t—using a mathematical hash function. The result of encrypting the digest with a private key is a signature, which is sent with the message.

The receiver can decrypt the message and re c reate the digest using the same hash function. Decrypting the signature with the sender’s public key produces the original digest. If the digests match, the receiver can be certain that the message was actually sent by the signer and hasn’t been altered in transit.

In this way, public key cry p t o g r a p h y e n s u res both authenticity and integrity. It also ensures that the sender can’t later deny having sent the message.

Дайджесты

Чтобы получатель мог убедиться в подлинности полученного сообщения, отправитель ставит на нем свою электронную подпись. Сначала пользователь при помощи математической хэш-функции получает уникальный отпечаток (дайджест) сообщения. После шифрования дайджеста секретным ключом создается сигнатура, которая отправляется вместе с сообщением. Получатель декодирует сообщение и восстанавливает дайджест с помощью той же хэш-функции. Декодирование сигнатуры открытым ключом отправителя помогает воссоздать прежний образ дайджеста. Если дайджесты совпадают, получатель может быть уверен в том, что сообщение действительно было отправлено тем человеком, который поставил на нем свою электронную подпись, и не подвергалось в пути никаким изменениям.

Таким образом, технология шифрования с открытым ключом обеспечивает целостность и достоверность информации. Кроме того, впоследствии отправитель уже не сможет отрицать факт пересылки данного сообщения.

Public key certificates

A public key c e rt i fic a t e is a digital document that irrevocably binds a person’s identity to a public key. Cert i ficates can be used as p a rt of a process to sign digital documents in a legally binding manner or to guarantee that a message is communicated only to intended p a rties. Like digital signatures, cert i fic a t e s help guarantee an individual’s identity.

A c e rtification authority (CA) cre a t e s c e rt i ficates. A CA can be a service run by or on behalf of a community of intere s t that decides who should have membership privileges in the community. A CA can also be a government body that issues cert i ficates to the public in conjunction with legislation governing the interpretation of digital signature s .

Сертификаты открытых ключей

Сертификат открытого ключа - это цифровой документ, позволяющий однозначно идентифицировать пользователя с открытым ключом. Сертификаты предназначены, для того чтобы удостоверить подлинность цифровых документов и гарантировать доставку сообщения только тем людям, которым оно адресовано. Как и цифровые подписи, сертификаты используются в качестве своеобразного персонального кода.

Выдачей сертификатов занимаются специальные уполномоченные службы CA (certification authority), своего рода клубы по интересам. Они самостоятельно определяют, кого следует принять в число своих членов, а кого нет. Такая служба может быть и правительственной организацией, которая выдает сертификаты пользователям и одновременно предоставляет правительству информацию о том, как следует интерпретировать тот или иной сертификат.

Communities of interest

A community of intere s t (COI) is like a c o u n t ry or even a country club. Yo u ’ re either a member or you’re not. Unlike countries, communities of interest know no geopolitical boundaries. In fact, they know no fixed boundaries at all. For example, a magazine’s readership is a COI. If a magazine were to make its editorial material available on the Internet only to that readership, it becomes a true COI. S h o rtly after the advent of cert i ficate technology, it became clear that communication among CAs is critical. Now, a COI can decide whether to honor the cert i ficates issued by the CA of another COI. Each COI can honor outside cert i ficates in any way it chooses, fro m considering the cert i ficates equivalent to its own, to restricting access to a subset of its information space. The restriction level is e n t i rely up to each COI and its CA.

Группа по интересам

Группа по интересам (community of interests, COI) - это некое подобие клуба. Вы можете либо входить в число членов этого клуба, либо нет. В отличие от государств группам по интересам незнакомы геополитические границы. Точнее говоря, для них вообще не существует никаких постоянных границ.

Например, читатели журнала - это COI. Если журнал публикует материалы в Internet только для ограниченной группы читателей, то он тоже представляет собой COI.

Вскоре после появления технологии сертификатов стало ясно, какое большое значение приобретает организация взаимодействия между различными службами CA. Группа по интересам решает, стоит ли признавать сертификаты, которые были выпущены службой CA, подчиняющейся другой COI. Каждая группа COI интерпретирует чужие сертификаты так, как ей захочется. Сертификаты других групп могут быть приравнены к своим собственным, а могут быть ограничены в правах. Для каждой группы COI и службы CA устанавливается свой уровень ограничений.

Unknown users

Even if a COI has never seen a part i c ular user before, it can decide to grant access on the basis of the cert i fic a t e ’s signature. The COI essentially says, “I don’t know you, but I know and trust your CA. On the basis of that trust, I’m willing to give you access to this inform a t i o n . ” What happens when someone with a c e rt i ficate from a here t o f o re unknown CA a p p roaches the boundary of a COI? The local COI has several choices. It can simply deny access and say, in effect, “Go a w a y. I don’t know you or the guy who signed your cert i fic a t e . ” A l t e rn a t i v e l y, the COI’s defenses can try to authenticate the user. One way of doing this is to search the GPKI to see how that CA stands in relation to CAs that might be known to the COI. For example, if the unknown CA is a subsidiary of another CA known to the COI, then the COI has some basis for deciding to trust the presented cert i fic a t e . Another way of addressing this issue is to have an implicit hierarchy of CAs implied by the order of multiple signat u res on the certificates of users. When p resented at the gates of a COI, the cert i fic a t e ’s signatures can be checked one by one, in ord e r, until the COI finds a signat u re from a CA that it already knows.

Неизвестные пользователи

Даже если группа COI никогда раньше не видела того или иного пользователя, она может предоставить ему требуемый доступ на основе сигнатуры сертификата. Группа общих интересов сообщает незнакомцу примерно следующее: "Мне ничего не известно о вас лично, но зато я хорошо знаю вашу службу CA и доверяю ей. Этот уровень доверия позволяет мне предоставить вам доступ к нужной информации".

Что произойдет, если какой-либо обладатель сертификата, выданного неизвестной группе общих интересов службой CA, приблизится к границам COI? У COI имеется несколько вариантов действий. Можно просто запретить доступ и грозно предупредить: "Стой, запретная зона! У нас нет информации ни о вас, ни о том парне, который подписал этот сертификат".

Но можно поступить и по-другому. В этом случае служба безопасности COI попытается идентифицировать пользователя. Один из способов заключается в поиске инфраструктуры GPKI и определении, в каких отношениях данная CA находится со службой CA, которая известна группе COI. К примеру, если неизвестная CA входит в состав службы CA, информация о которой имеется в группе общих интересов, то у COI появляются достаточные основания для того, чтобы доверять предъявленному сертификату.

Другим способом адресации является отражение скрытой иерархии служб CA за счет расположения сигнатур сертификатов пользователей в определенном порядке. При вступлении на территорию COI сигнатуры сертификатов последовательно проверяются, до тех пор, пока группа COI не обнаружит сигнатуру известной ей службы CA.

Certificate status and other attributes

For some transactions, it is not enough to rely merely on the signature of the issuing CA. When sensitive data is being accessed, it may be necessary to determ i n e the validity of the cert i ficate at the time of the transaction. For this reason, there are a variety of cert i ficate status mechanisms.

The older approach—known as a c e r - tificate revocation list (CRL)—is maintained by a CA for the cert i ficates it has issued. In this paradigm, cert i ficates issued by a CA are considered valid unless they appear on the CRL. This approach mirrors the way credit card transactions were p rocessed some decades ago and suff e r s f rom the same drawbacks.

A newer approach—still under stand a rds development—relies on networked d i re c t o ry services to provide real-time cert i ficate status information via an online certificate status pro t o c o l (OCSP). In this paradigm, cert i ficates issued by a CA are assumed to be invalid until their status is retrieved from the dire c t o ry maintained by the CA. One of the advantages of an OCSP model is that it can be extended to pro v i d e i n f o rmation about other user attributes, like credit card numbers or home addresses .

Статус сертификата и другие атрибуты

При выполнении некоторых транзакций нельзя ограничиваться сравнением сигнатуры, предоставленной службой CA. Перед предоставлением доступа к важным данным необходимо дополнительно проверить достоверность сертификата непосредственно во время транзакции. Для решения этой задачи вводятся различные механизмы определения статуса сертификата.

Самый старый способ заключается в ведении списка аннулированных сертификатов (certificate revocation list, CRL), который поддерживается службой CA для всех выданных ею цифровых документов. Сертификаты, выданные CA, считаются достоверными до тех пор, пока они не окажутся в списке CRL. Данный подход аналогичен способу выполнения транзакций, который применялся несколько десятков лет тому назад в кредитных картах. Ему были присущи те же недостатки.

Более новый метод (его стандарт в настоящее время находится в процессе разработки) основан на использовании службы сетевых каталогов, которая предоставляет информацию о статусе сертификата в режиме реального времени при помощи протокола статуса сертификата OCSP (online certificate status protocol). В этом случае сертификаты, выданные службой CA, считаются недействительными до тех пор, пока информация об их статусе не будет выбрана из каталога, поддерживаемого CA. Одно из преимуществ модели OCSP состоит в том, что предоставляемая информация может быть расширена за счет включения других пользовательских атрибутов (например, номера кредитной карты или домашнего адреса).

27702

32104