Шифрует ли скайп данные

Обновлено: 07.07.2024

Skype представляет собой одну из самых популярных VoIP-программ, установленную на миллионах компьютеров по всему миру, владельцы которых даже и не подозревают, какая опасность им грозит. А опасность им грозит весьма серьезная: от утечки конфиденциальной информации до проникновения червей и попадания на трафик, не говоря уже о таких мелочах, как нежелание Skype работать при активном SoftICE. Я все это благополучно разгрыз и теперь выставляю продукты своей жизнедеятельности на всеобщее обозрение :).

Skype, созданный отцами-основателями скандально известной Kazaa и унаследовавший от своей прародительницы самые худшие ее черты, работает по принципу самоорганизующейся распределенной пиринговой сети (distributed self-organized peer-to-peer network, P2P). Skype – это черный ящик с многоуровневой системой шифрования, напичканного антиотладочными приемами исполняемого файла, считывающий с компьютера конфиденциальную информацию и передающий ее в сеть по закрытому протоколу. Последний обходит брандмауэры и сурово маскирует свой трафик, препятствуя его блокированию. Все это превращает Skype в идеального переносчика вирусов, червей и дронов, создающих свои собственные распределенные сети внутри Skype-сети. К тому же, Skype довольно бесцеремонно обращается с ресурсами твоего узла, используя его для поддержания связи между остальными узлами Skype-сети, напрягая ЦП и генерируя мощный поток трафика. А трафик, как известно, редко бывает бесплатным (особенно в России), так что кажущаяся бесплатность звонков весьма условна: за узлы с «тонкими» каналами расплачиваются «толстые» владельцы.

Skype активно изучается в хакерских лабораториях и security-организациях по всему миру, и большинство исследователей единодушно сходятся во мнении, что Skype - это дьявольски хитрая программа, написанная бесспорно талантливыми людьми в стиле
Black Magic Art. Skype не брезгует грязными трюками, создающими огромные проблемы, о которых я и собираюсь рассказать.

Анализ исполняемого файла Skype

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

Двоичный файл полностью зашифрован и динамически расшифровывается по мере загрузки в память. Причем сброс дампа невозможен, точнее, затруднен тем обстоятельством, что стартовый код после выполнения очищается, в результате чего мы получаем exe, который не запускается. Оригинальная таблица импорта не содержит ничего интересного, и API-функции подключаются уже в процессе распаковки. Проверка целостности кода выполняется из разных мест в случайном порядке (преимущественно при входящих звонках), поэтому поиск защитных процедур представляет собой весьма нетривиальную задачу. Тем более что они основаны на криптографических RSA-сигнатурах и снабжены полиморфными генераторами, которые в случайном порядке переставляют инструкции ADD, XOR, SUB и др., перемешивая их с левыми машинными командами.

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

А вот про отладчик следует сказать отдельно. Skype распознает
SoftICE даже при наличии установленного IceExt, наотрез отказываясь запускаться. Это забавно, поскольку для взлома самого Skype отладчик
SoftICE не очень-то и нужен, ведь существуют и другие инструменты подобного рода, среди которых в первую очередь хотелось бы отметить
The Rasta Ring 0 Debugger, или сокращенно [RR0D], не обнаруживаемый Skype-клиентом и, как и следует из его названия, работающий на уровне ядра. В принципе, можно воспользоваться и отладчиком прикладного уровня (например, стремительно набирающим популярность
OllyDbg). Только при этом важно помнить, что Skype легко обнаруживает программные точки останова, представляющие собой однобайтовую машинную инструкцию с опкодом CCh, записывающуюся поверх отлаживаемого кода. А для предотвращения пошаговой трассировки Skype осуществляет замеры времени выполнения определенных участков кода, для прохождения через которые приходится использовать полноценные эмуляторы PC с интегрированным отладчиком, например, знаменитый
BOCHS.

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

Последовательность распаковки исполняемого
файла

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

Проблема в том, что Skype очень следит за своей целостью, поэтому попытка исправления jnz на jmp short работает только до первого входящего звонка, после которого Skype падает и обратно уже не поднимается. Специально для таких хитроумных защит еще во времена MS-DOS была разработана техника онлайн-патча, при которой исправление программы осуществляется непосредственно в оперативной памяти, а после успешного прохождения проверки на наличие
SoftICE совершается откат, чтобы не волновать процедуру проверки целости.

Беглая трассировка Skype с помощью OllyDbg быстро выявляет защитный код, выполняющий проверку на присутствие SoftICE

Архитектура распределенной сети

На атомарном уровне структура Skype-сети состоит из обычных узлов (normal/ordinal node/host/nest), обозначаемых аббревиатурой SC (Skype
Client), и super-узлов (super node/host/nest), которым соответствует аббревиатура SN. Любой узел, который имеет публичный IP-адрес (тот, который маршрутизируется в интернет) и обладает достаточно широким каналом, автоматически становится super-узлом и гонит через себя трафик обычных узлов, помогая им преодолеть защиты типа брандмауэров или трансляторов сетевых адресов (NAT) и равномерно распределяя нагрузку между хостами. В этом и состоит суть самоорганизующейся распределенной децентрализованной пиринговой сети, единственным централизованным элементом которой является
Skype-login-сервер, отвечающий за процедуру авторизации Skype-клиентов и гарантирующий уникальность позывных для всей распределенной сети.

Важно подчеркнуть, что связь между узлами осуществляется не напрямую, а через цепочку super-узлов. Серверов в общепринятом смысле этого слова (таких, например, как в сети eDonkey) в Skype-сети нет. Любой узел с установленным Skype-клиентом является потенциальным сервером, которым он автоматически становится при наличии достаточных системных ресурсов (объема оперативной памяти, быстродействия процессора и пропускной способности сетевого канала).

Каждый узел Skype-сети хранит перечень IP-адресов и портов известных ему super-узлов в динамически обновляемых кэш-таблицах (Host Cache Tables, HC-tables). Начиная с версии Skype 1.0, кэш-таблица представляет собой простой XML-файл, в незашифрованном виде записанный на диске в домашней директории пользователя.

Структура децентрализованной самоорганизующейся пиринговой
Skype-сети

Skype-клиенты за отдельную плату могут принимать входящие звонки с обычных телефонов и совершать подобные звонки. Однако в PC2PC-обмене эти серверы никак не участвуют, поэтому мы не будем на них останавливаться.

Помимо звонков внутри Skype-сети, пользователи могут звонить и на обычные телефоны, а также принимать с них звонки.

Как Skype обходит брандмауэры

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

Структура IP-пакета при работе Skype по протоколу UDP

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

Механизм шифрования, используемый Skype

Так что, с юридической точки зрения, действия Skype законны и не попадают под статью.
STUN, расшифровывающийся как Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (простое проникновение датаграмм протокола UDP через транслятор сетевых адресов (NAT)), представляет собой отличное средство, которое страдает, однако, рядом ограничений и не работает в следующих случаях:

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

Эта проблема решается протоколом TURN (Traversal Using Relay
NAT), технические подробности работы которого описаны по вышеупомянутому адресу и большинству читателей совершенно неинтересны. Гораздо важнее другое — протокол TURN значительно увеличивает латентность и теряет большое количество UDP-пакетов (packet loss), что далеко не лучшим образом сказывается на качестве и устойчивости связи, но полное отсутствие связи - еще хуже. Так что пользователям Skype стоит радоваться, а не жаловаться!

Структура Skype-сети, в которой присутствуют
Skype-клиенты за NAT и брандмауэрами

Вот только администраторы этой радости почему-то не разделяют, наглухо закрывая UDP-трафик (тем более что большинству нормальных программ он не нужен). Немного поворчав для приличия (замуровали, демоны!), Skype автоматически переключается на чистый TCP, отрубить который администратору никто не позволит. Правда, поколдовав над брандмауэром, тот может закрыть все неиспользуемые порты, но в том-то и подвох, что неиспользуемых портов в природе не встречается! При соединении с удаленным узлом операционная система назначает клиенту любой свободный TCP/UDP-порт, на который будут приходить пакеты. То есть, если мы подключаемся к web-серверу по 80-му порту, наш локальный порт может оказаться 1369-м, 6927-м или еще каким-нибудь другим. Закрыв все порты, мы лишимся возможности устанавливать TCP/UDP-соединения!

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

Skype, работающий через proxy-сервер, конфигурация которого прочитана из настроек браузера

Как заблокировать Skype-трафик

Разработчики Skype предостерегают администраторов от попыток выявления и блокирования его трафика (типа: «Все равно у вас ничего не получится!»). И действительно, распознать Skype-трафик очень сложно, а заблокировать его можно только по содержимому, которое зашифровано и не содержит никаких предсказуемых последовательностей. К счастью для администраторов, создатели Skype, при всей своей гениальности, допустили ряд оплошностей, оставив часть трафика незашифрованной. UDP-соединение использует открытый протокол для получения публичных IP-адресов super-узлов, что вполне может быть выявлено анализатором трафика. Это раз. TCP-соединение использует один и тот же RC4-поток дважды, что позволяет нам восстановить 10 первых байт ключа, расшифровав часть постоянных полей заголовков Skype-протокола. Это два! Кстати, весьма полезная вещь для шпионажа за чужими разговорами! Однако мне не известен ни один готовый блокиратор Skype-трафика, а писать свой собственный — лениво, да и времени нет.

Повторное использование RC4-потока позволяет восстановить 10 байт ключа из 12-ти, расшифровывая часть Skype-трафика

Распознать и заблокировать UDP-трафик намного проще. Каждый фрейм начинается с двухбайтового идентификационного номера (ID) и типа пакета (payload). В UDP-пакет вложен 39-байтный NACK-пакет, пропущенный через обфускатор и содержащий следующие данные:

идентификатор пакета (непостоянен и варьируется от пакета к пакету);
номер функции (func), пропущенный через обфускатор, но func & 8Fh всегда равно 7h;
IP отправителя;
IP получателя.

Таким образом, чтобы заблокировать UDP-трафик, генерируемый Skype, достаточно добавить в брандмауэр следующее правило:

iptables -I FORWARD -p udp -m length --length 39 -m u32
--u32 '27&0 x8f=7' --u32 '31=0 x527c4833 ' -j DROP

Структура NACK-пакета

К сожалению, блокировка UDP-трафика ничего не решает, поскольку Skype автоматом переходит на TCP, но тут есть одна небольшая зацепка. Заголовки входящих IP-пакетов, относящиеся к протоколу обмена SSL-ключами
(SSL key-exchange packets), содержат нехарактерный для «нормальных» приложений идентификатор 170301h, возвращаемый в ответ на запрос с идентификатором 160301h (стандартный SSL версии 3.1). Таким образом, блокирование всех входящих пакетов, содержащих в заголовке 170301h, серьезно озадачит Skype, и текущие версии потеряют работоспособность. Вот только надолго ли…

Распознание Skype-трафика по необычному идентификатору во время обращения к Login Server при обмене SSL-ключами

Для детектирования и блокирования Skype-трафика можно использовать и другие программно-аппаратные средства, например, PRX от Ipoque или Cisco Network-Based Application Recognition (NBAR). Однако все они недостаточно эффективны, так как разработчики Skype не сидят сложа руки, и если кому-то удается найти надежный способ блокировки его поганого трафика, в следующих версиях поганец появляется вновь.

Армии дронов, или как зомбировать Skype

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

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

Другая опасная «вкусность» Skype заключается в открытости его API. Пойдя навстречу сторонним разработчикам, создатели Skype предусмотрели возможность интеграции любой прикладной программы со
Skype-клиентом. Правда, при этом на экран выводится грозное предупреждение, что такая-то программа хочет пользоваться Skype API: разрешить или послать ее на фиг? Естественно, большинство пользователей на подобные вопросы отвечают утвердительно. Уже привыкшие к надоедливым предупреждениям, они инстинктивно давят «Yes» и только потом начинают думать, а что же они, собственно, разрешили?

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

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

Географическое распределение super-узлов Skype по планете

Заключение

Заканчивая статью, я хотел бы спросить: что же все-таки скрывают создатели Skype в недрах своего кода? Почему, распространяя программу бесплатно, они зажимают исходные тексты и используют закрытый протокол, вызывая тем самым недоверие специалистов по безопасности? Для чего бесплатной программе столь навороченная защита, снижающая производительность и потребляющая большое количество памяти, ведь ломать ее никто не собирается? Почему вообще Skype-клиент реализован как черный ящик?

Вопросы риторические. Но чует мой хвост, неспроста все это!

WWW

Полную версию статьи
читай в апрельском номере
Хакера!

СОДЕРЖАНИЕ

Политика безопасности

Политика безопасности компании гласит:

Реализация и протоколы

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

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

Затем устанавливается сеанс с 256-битным шифрованием AES с сервером Skype. Клиент создает сеансовый ключ, используя свой генератор случайных чисел .

Сервер Skype проверяет, что выбранное имя пользователя уникально и соответствует правилам именования Skype. Сервер хранит имя пользователя и хэш пароля пользователя в своей базе данных. [ ЧАС ( ЧАС ( п ) ) ]

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

Одноранговое соглашение о ключе

Сессионная криптография

Генерация случайных чисел

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

Криптографические примитивы

Skype использует стандартные криптографические примитивы для достижения своих целей безопасности. В Skype используются следующие криптографические примитивы: блочный шифр AES, криптосистема с открытым ключом RSA, схема заполнения подписи ISO 9796-2, хэш-функция SHA-1 и потоковый шифр RC4 .

Протокол ключевого соглашения

Согласование ключей достигается с помощью проприетарного симметричного протокола. Для защиты от атак воспроизведения одноранговые узлы бросают вызов друг другу случайными 64-битными одноразовыми номерами . Ответ на запрос состоит в том, чтобы настроить запрос частным образом и вернуть его, подписанный закрытым ключом респондента.

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

Автоматические обновления

Еще одна угроза безопасности - это автоматические обновления, которые нельзя отключить с версии 5.6 как в Mac OS, так и в ветках Windows, хотя в последней версии и только с версии 5.9 в некоторых случаях автоматическое обновление может быть отключено.

Подслушивание по замыслу

Правоохранительные органы Китая, России и США имеют возможность подслушивать разговоры по Skype и иметь доступ к географическим местоположениям пользователей Skype. Во многих случаях достаточно простого запроса информации без одобрения суда. Эта возможность была намеренно добавлена Microsoft для правоохранительных органов по всему миру после того, как они приобрели Skype в 2011 году. Это реализовано путем переключения клиента Skype для конкретной учетной записи пользователя с шифрования на стороне клиента на шифрование на стороне сервера, что позволяет распространять незашифрованный поток данных.

Фактические и потенциальные недостатки

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

Другая сторона безопасности заключается в том, представляет ли Skype риск для компьютеров и сетей своих пользователей. В октябре 2005 года было обнаружено и исправлено несколько недостатков в системе безопасности. Эти недостатки позволяли хакерам запускать вредоносный код на компьютерах с уязвимыми версиями Skype. Первая ошибка безопасности затронула только компьютеры Microsoft Windows . Это позволяло злоумышленнику использовать переполнение буфера для сбоя системы или для принудительного выполнения произвольного кода. Злоумышленник может предоставить искаженный URL-адрес, используя формат URI Skype , и побудить пользователя запросить его для выполнения атаки. Вторая ошибка безопасности затронула все платформы; он использовал переполнение буфера на основе кучи, чтобы сделать систему уязвимой.

Проблемы, в том числе несколько потенциально влияющих на безопасность, включают:

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

Skype для бизнеса

SharePoint Online и OneDrive для бизнеса

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

Несколько рабочих нагрузок в Microsoft 365 хранят данные в SharePoint Online, включая Microsoft Teams, которая хранит все файлы в SharePoint Online и OneDrive для бизнеса, которая использует SharePoint Online для своего хранения. Все данные клиентов, хранимые в SharePoint Online, шифруются (с одним или более 256-битными ключами AES) и распространяются по центру обработки данных следующим образом. (Каждый шаг этого процесса шифрования является проверкой FIPS 140-2 Level 2. Дополнительные сведения о соответствии требованиям FIPS 140-2 см. в см. в руб.)

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

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

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

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

Ключи, используемые для шифрования blobs, хранятся в SharePoint базе данных контента в Интернете.
База данных контента защищена средствами управления доступом к базе данных и шифрованием в покое. Шифрование выполняется с прозрачное шифрование данных (TDE) в База данных SQL Azure. (База данных SQL Azure — это служба реляционных баз данных общего назначения в Microsoft Azure, которая поддерживает такие структуры, как реляционные данные, JSON, spatial и XML.) Эти секреты находятся на уровне службы SharePoint Online, а не на уровне клиента. Эти секреты (иногда называемые главными ключами) хранятся в отдельном безопасном репозитории под названием Key Store. TDE обеспечивает безопасность как для активной базы данных, так и для резервных копий баз данных и журналов транзакций.
Когда клиенты предоставляют необязательный ключ, ключ клиента хранится в хранилище ключей Azure, а служба использует ключ для шифрования ключа клиента, который используется для шифрования ключа сайта, который затем используется для шифрования ключей уровня файлов. По сути, когда клиент предоставляет ключ, вводится новая иерархия ключей.

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

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

Данные клиента хранятся в виде зашифрованных blobs в хранилище Azure. Ключ к каждому фрагменту данных клиента шифруется и хранится отдельно в базе данных контента. Сами данные клиента не имеют представления о том, как их можно расшифровать.
База данных контента это база данных SQL Server. В нем содержится карта, необходимая для обнаружения и повторного сбора blobs данных клиента, хранимого в хранилище Azure, а также ключей, необходимых для шифрования этих blobs. Однако набор ключей сам шифруется (как поясняется выше) и хранится в отдельном хранилище ключей.
Хранилище ключей физически отделено от базы данных контента и хранилища Azure. Он содержит учетные данные для каждого контейнера хранения Azure и главный ключ к набору зашифрованных ключей, хранимым в базе данных контента.

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

Сертификаты BitLocker, защищающие физические объемы дисков на компьютерах центра обработки данных, хранятся в безопасном репозитории (хранилище секретов SharePoint Online), защищенном ключом Farm.

Ключи TDE, защищающие клавиши на blob, хранятся в двух расположениях:

Безопасное репозиторий, в котором находятся сертификаты BitLocker и защищены ключом фермы; и
В безопасном репозитории, управляемом База данных SQL Azure.

Учетные данные, используемые для доступа к контейнерам хранения Azure, также хранятся в секретном хранилище SharePoint Online и делегируют каждой ферме SharePoint Сети по мере необходимости. Эти учетные данные являются подписями SAS хранилища Azure, с отдельными учетными данными, используемыми для чтения или записи данных, и с политикой, применяемой таким образом, чтобы они автоматически истекали каждые 60 дней. Различные учетные данные используются для чтения или записи данных (не обоих), и SharePoint фермам в Интернете не дают разрешений на переумериять.

Для Office 365 правительственных клиентов США blobs данных хранятся в Azure правительственных служба хранилища. Кроме того, доступ к SharePoint в Интернете Office 365 в правительстве США ограничен Office 365 сотрудниками, которые были специально экранирована. Сотрудники правительственных операций Azure в Сша не имеют доступа к магазину ключей SharePoint Online, который используется для шифрования blobs данных.

Дополнительные сведения о шифровании данных в SharePoint Online и OneDrive для бизнеса см. в OneDrive для бизнеса и SharePoint Online.

Список элементов SharePoint Online

Шифрование транзитных данных

В OneDrive для бизнеса и SharePoint Online используются два сценария для входящих и исходящих данных в центрах данных.

Клиентская связь с сервером . Связь SharePoint в Интернете и OneDrive для бизнеса через Интернет использует TLS-подключения.
Перемещение данных между центрами обработки данных . Основной причиной перемещения данных между центрами обработки данных является гео репликация для обеспечения аварийного восстановления. Например, SQL Server журналы транзакций и дельты хранения blob путешествуют по этой трубе. Хотя эти данные передаются по частной сети, они дополнительно защищены лучшим в своем классе шифрованием.

Exchange Online

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

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

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

Microsoft Teams

В этой таблице подводятся итоги протоколов, используемых Teams.

Шифрование мультимедиа

Трафик мультимедиа шифруется с помощью secure RTP (SRTP), профиля протокола транспорта Real-Time (RTP), который обеспечивает конфиденциальность, проверку подлинности и защиту от атак повторно для трафика RTP. SRTP использует ключ сеанса, созданный с помощью безопасного генератора случайных чисел и обменивается с помощью сигнального канала TLS. Трафик мультимедиа от клиента к клиенту ведется через сигнализацию подключения клиента к серверу, но шифруется с помощью SRTP при непосредственном движении от клиента к клиенту.

Teams использует маркер на основе учетных данных для безопасного доступа к ретранслятору мультимедиа через TURN. Ретрансляторы мультимедиа обмениваются маркером через канал, защищенный TLS.

Teams fiPS (Федеральный стандарт обработки информации) для обмена ключами шифрования. Дополнительные сведения о реализации FIPS см. в публикации 140-2Федерального стандарта обработки информации (FIPS).

Можно ли подслушать переговоры по Skype? Если от соблюдения тайны зависят жизнь и свобода, лучше не экспериментировать, а использовать более безопасные альтернативы.

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

Еще в 2008 году боссы Skype, тогда принадлежавшего Ebay, заявили в интервью CNET, что шифрование в сочетании с одноранговой (p2p) архитектурой сервиса делают перехват переговоров делом невозможным – кроме как на компьютерах собеседников ключи шифрования нигде не хранятся. А поскольку головной офис находится не в США, компания не обязана сотрудничать с американскими спецслужбами. Если вы в курсе событий в сфере сетевой безопасности, то вам хорошо известно, что в 2011 году сервис Skype стал наиболее известным многомиллиардным приобретением софтверного гиганта Microsoft.

Так как с этого времени Skype стал принадлежать американской компании, то деятельность сервиса должна отвечать американским законам, в частности, принятому в 1994 году Закону о прослушивании телефонных переговоров (CALEA), который американские правоохранительные органы используют для получения данных о террористах и других подозреваемых. Однако, в интервью газете Нью-Йорк Таймс представитель Microsoft утверждал, что штаб-квартира Skype остается в Люксембурге, и что компания таким образом не подпадает под действие законов США.

Несмотря на это, эксперты по безопасности не убеждены в отсутствии прослушивания, и многие из них, например члены Electronic Frontier Foundation, подписали в январе открытое письмо, в котором Microsoft призывают детально описать политику Skype по данным вопросам.

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

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

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

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

К счастью, некоторые из наших невероятно умных друзей в отрасли работают над такими альтернативными решениями, хотя вам, возможно, придется платить за них. Мокси Марлинспайк (Moxie Marlinspike) открыл компанию Whisper Systems, которая производит приложения с открытым исходным кодом для безопасной связи и хранения данных. Silent Circle Фила Циммермана предлагает двустороннее шифрование между пользователями на iOS и Android-устройствах. Jitsi –это еще один хороший вариант, который предлагает безопасный чат, видеоконференции и передачи данных и совместим с рядом существующих популярных приложений. The Open Secure Telephony Network разработала клиент Ostel, который пока ещё находится в публичном бета-тесте, но уже предлагает двусторонние шифрование и аутентификацию при передаче голоса в мобильных и настольных платформах. Есть, конечно, и еще варианты, так что будем рады вашим комментариям о выбранном способе защиты связи.

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

Читайте также: