Цели

2. Цели

Целями протокола TLS в порядке приоритетности являются:

Криптографическая безопасность. TLS должен использоваться для установления безопасного соединения между двумя партнерами.

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

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

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

3. Цели данного документа

Этот документ и сам протокол TLS базируются на спецификации протокола SSL 3.0, опубликованного Netscape. Различие между этим протоколом и SSL 3.0 не значительны, но они вполне достаточны, чтобы сделать TLS 1.0 и SSL 3.0 не совместимыми (хотя TLS 1.0 имеет механизм, с помощью которого приложения могут поддерживать SSL 3.0). Этот документ предназначен, прежде всего, для читателей, которые будут создавать протокольные приложения, и осуществлять их криптографический анализ. Спецификация была написана именно с такими намерениями и именно для этих двух групп разработчиков. Для этой цели многие правила и структуры данных, зависимые от алгоритма, включены в текст (а не в приложение), обеспечивая более легкий к ним доступ.

4. Язык представления

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

4.1. Базовый размер блока

Базовым блоком данных считается один байт (т.e. 8 бит). Многобайтовые информационные элементы представляют собой объединение последовательности байтов слева направо и сверху вниз. Многобайтовые элементы извлекаются из байтового потока (используя нотацию Си) следующим образом:

value = (байт[0]

Этот порядок байтов для многобайтовых последовательностей является стандартным для сетей (big endian).

4.2. Разное

Комментарии начинаются с "/*" и завершаются "*/". Опционные компоненты выделяются с помощью помещения их в двойные квадратные скобки "[[ ]]". Однобайтовые объекты, содержащие не интерпретируемые данные, имеют 'непрозрачный' тип (opaque).

4.3. Векторы

Вектор (одномерный массив) является потоком однородных информационных элементов. Размер вектора может быть специфицирован во время документирования или оставаться не специфицированным вплоть до начала работы. В любом случае длина определяет число байтов, а не число элементов в векторе. Синтаксис спецификации нового типа T', который является вектором фиксированной длины типа T, имеет вид T T'[n];

Здесь T' занимает в информационном потоке n байт, где n кратно размеру T. Длина вектора не включается в кодированный поток.

В следующем примере Datum определен, как три последовательные байта, которые не интерпретируются протоколом, в то время как Data представляет собой три вектора Datum, состоящие из девяти байт.

opaque Datum[3];	/* три не интерпретируемые байта */
Datum Data[9];	/* 3 последовательных 3-байтовых вектора */

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

T T';

В следующем примере, обязательным является вектор, который должен содержать от 300 до 400 байт непрозрачного типа. Он не должен быть пустым. Поле действительной длины занимает два байта, uint16, достаточных, чтобы представить значение 400 (смотри раздел 4.4). С другой стороны, longer может представить до 800 байт данных, или 400 uint16 элементов, и может быть пустым. Его кодовое представление будет включать два байта поля реальной длины, за которым будет следовать вектор. Длина закодированного вектора должна быть четной, кратной длине одиночного элемента (например: 17-байтовый вектор uint16 будет нелегальным).

opaque mandatory;	/* поле длины имеет 2 байта, не может быть пустым */
uint16 longer;	/* 0 - 400 16-битовое целое число без знака */

4.4. Числа

Базовый числовой тип данных представляет собой байт без знака (uint8). Все более длинные типы цифровых данных образуются из фиксированной последовательности байт без знака, объединенных вместе, как это описано в разделе 4.1,. Следующие числовые типы являются предопределенными.

uint8 uint16[2];

uint8 uint24[3];

uint8 uint32[4];

uint8 uint64[8];

Все значения здесь и в дальнейшем записываются в 'сетевом порядке' (big-endian); uint32 представленное шестнадцатеричными байтами 01 02 03 04 эквивалентно десятичному значению 16909060.

4.5. Нумерованный тип

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

enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

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

enum { red(3), blue(5), white(7) } Color;

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

enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

Имена элементов нумерации собраны в пределах определенного типа. В первом примере, полная ссылка на второй элемент будет выглядеть как Color.blue. Такое описание не требуется, если объект присвоения (target) хорошо специфицирован.

Color color = Color.blue;	/* чрезмерная спецификация, допустимо */
Color color = blue;	/* правильно, тип задан неявно */

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

enum { low, medium, high } Amount;

4.6. Сконструированные типы

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

struct {

	T1 f1;
	T2 f2;
	...
	Tn fn;} [[T]];

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

4.6.1. Варианты

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

struct {

	T1 f1;
	T2 f2;
	....
	Tn fn;
	select (E) {
	case e1: Te1;
	case e2: Te2;
	....
	case en: Ten;
	} [[fv]];} [[Tv]];

Например:

enum { apple, orange } VariantTag;

struct {

	uint16 number;
	opaque string; /* переменная длина */
	} V1;

<

/p> struct {

	uint32 number;
	opaque string[10]; /* фиксированная длина */
	} V2;

struct {

	select (VariantTag) {	/* value of selector is implicit */
	case apple: V1;	/* VariantBody, tag = apple */
	case orange: V2;	/* VariantBody, tag = orange */
	} variant_body;	/* optional label on variant */
	} VariantRecord;

Структуры варианта могут быть подготовлены (сужены) путем спецификации значения селектора до спецификации типа. Например: orange VariantRecord является суженным типом для VariantRecord, содержащего variant_body типа V2.

4.7. Криптографические атрибуты

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

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

В подписи RSA, 36-байтовая структура двух хэшей (один SHA и один MD5) кодируется с помощью секретного ключа. Описание кодировки смотри в [PKCS1].

В DSS, 20 байтов хэша SHA передаются непосредственно алгоритму цифровой подписи DSA (Digital Signing Algorithm) без дополнительного хэширования. В результате получаются числа r и s. Подпись DSS представляет собой непрозрачный вектор, содержимое которого представляет собой результат DER-кодирования:

DssSigValue ::= SEQUENCE {	r	INTEGER,
	s	INTEGER}

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

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

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

В следующем примере:

stream-ciphered struct {

	uint8 field1;
	uint8 field2;
	digitally-signed opaque hash[20];} UserType;

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

4.8. Константы

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

Например,

struct { uint8 f1; uint8 f2;} Example1;

Example1 ex1 = {1, 4};

/* assigns f1 = 1, f2 = 4 */

Содержание раздела