Security vs Cloud blog | Все запили alexey

Security vs Cloud blog

Здесь найдете заметки по безопасности, облакам и предпринимательству

Меняем парольв PFX/PKCS12-контейнере

Иногда всплывает элементарная задача - сменить или задать пароль на PFX-контейнер с сертификатом и ключем. И выливается это в запуск утилит OpenSSL из консоли. В общем из пушки по воробьям :)
При этом в .NET это делается всего за 3 шага.
Необходимо:
- Открыть PFX/PKCS12-контейнер с флагом, разрешающим экспорт закрытого ключа, указав старый пароль
- Вызвать метод Export с флагом X509ContentType.Pfx и новым паролем для получения нового контейнера в виде бинарного массива
- Сохранить массив на диск и вуаля - получаем новый контейнер.
При экспорте PFX-контейнера есть одна хитрость. Новый пароль задается с помощью класса SecureString. Для удобного получения объекта SecureString из обычной строки можно использовать небольшое расширение:

public static SecureString ToSecureString(this string input)
{
            if (string.IsNullOrWhiteSpace(input))
                return null;

            SecureString res = new SecureString();
            foreach (char c in input.ToCharArray())
                res.AppendChar(c);
            return res;
}

Само приложение с исходниками для изменения пароля на PFX-контейнеры в приложении

PFXChangePassword.zip (53,7KB)

Internet of Things из подручных средств

Если вы пришли на ИТ-конференцию и на ней не быо ни оного доклада по IoT или даже Internet of Everything, это не ИТ-шная конференция. 
Говорить про IoT стали лет 7 назад. Одной из ранних пташек на поприще IoT Была французская компания Violet.NET
Они в 2008 уже показывали на конференциях NFC-ридеры с датчиками в виде кроликов MIR:ROR. Выпоустили они их в 2010, но дело не поезало и в 2011 они уже сообщили о банкротстве.
В 2011 мне достался их девайсик, и захотелось с ним что-нибудь натворить. После мучительного выбора сценариев было решено прикрутить девайс к медиацентру - машинке на базе Intel Atom/Win7, подключенной к телевизору.

После серии экспериментов, оказалось, что для общения с ридером Mirror можно использовать библиотеки pcsc_desfire и замечательную для .NET (выложил их в аттаче).

Результат трудов заснят на видео:


И вот сейчас настал 2015 год. Я роюсь в материалах конференции IOT Summit London 2015 и нахожу поделки примерно такого же уровня. Вообще весь IoT с конференции можно разделить на 3 части:
- Умные дома (да-да уровня этих кроликов :))
- Умные футболки/шорты/подштанники
- Датчики, которые могут что-то мерять (ветер, осадки, шум) и рапортовать владельцу
Т.е. за это время реальные области применения IoT так и остаются вотчиной гиков. Видимо придется еще пару-тройку лет подожлать, прежде чем какая-нибудь корпорация, например со своим Win10 сможет расшевелить рынок настолько, чтобы туда пришли реальные потребители умных железяк.

А пока в аттаче библиотечка. Чуть позже выложу код целиком, как только слегка причешу и приведу его в порядок :)

NFC.rar (46,3KB)

Коротенько о PKI

Откуда пошла Инфраструктура Открытых Ключей? И почему именно Инфраструктура?
На самом деле появилась она самым логичнейшим способом - в результате эволюции. 
Вспомним Энигму и симметричные криптосистемы. Они стойкие, позволяют шифровать данные с огромной скоростью, но при большом числе абонентов приходятя использовать единые для всех ключи, иначе задача даставки ключевой инфомации становится нереальной. 
Например для 100 абонентов - нужно чуть меньше чем 100-факториал ключей. Блакнотов не хватит! :)
Значит приходится использовать общие ключи, а это значит теряется контроль. Стоит кому-то каким-либо способом получить ключ - он может читать любую переписку абонентов. Да и доказать, какая часть системы была скомпрометирована - не реально.
Когда появились ассиметричные криптосистемы ex RSA - ключи стали попарно независимы. Те это можно представить как почтовый ящик: Открытый ключ - номер дома и почтового ящика, а секртеный ключ - есть только у меня и позволяет мне этот ящит открыть.
Здесь на 100 абонентов нужно всего 100 пар ключей. 
Но и тут есть довольно банальные уязвимости. Открытый ключ должен доставляться доверенным способом или быть как-то проверяемым. Иначе мне могут подсунуть чужой ключ, я зашифрую данные для третьей строны, Они их прочтет, подправит и спокойно передаст дальше.
По аналогии с почтовым ящиком - если я пришел положить письмо, а кто-то взял и преписал номер ящика на свой. Я передам пимьо злоумышленнику, он его прочтет и уже потом может изменить и положить в ящик реального адресата.
Вот здесь и появляется Инфраструктура Открытых Ключей. 

Суть его проста - мы доставляем доверенно только 1 ключ нашего Главного Пользователя (Удостоверяющего Центра), а он заверяет все остальные ключи. И если мы получаем чей-то ключ то  начале проверяем его с помощью ключа УЦ.

На самом деле это объяснение на пальцах, и в PKI еще много интересныз и мощных инструментов, таких как политики, OID-ы, типы документов. 
Если интересно посмотреть как это все работает в картинках - в приложении презентация по введению в PKI :)

pki_one_day_introduction_lyubko.pdf (1,3MB)

Как мы используем CQRS в Azure

При построении высоконагруженных систем, есть одно простое требование к арзитектуре - горизонтальная масштабируемость. И под это требование есть довольно универсальное решение - использовать механизмы очередей, где это позволяет профиль проекта. И стараться минимизировать работу и коммуникации между компанентами системы, когда пользователь приходит за данными.
Именно эти две задачи весьма неплохо решает принцип CQRS - Command-Query Responsibility Segregation. Вернее принцип это заметно шире, но на базе очередей и разделения Worker/Web-Role его весьма неплохо можноздесь использовать.
Итак, давайте разберем, как работают наши Пряники (pryaniky.com), руководствуясь этим принципом:

Все начинается от запроса клиента. Допустим я пользователь, который решил отправить новое сообщение. Этот запрос через JSON прилетает на Web-роль Azure.
И вместо того чтобы сразу писать его в БД мы:
- делаем первичную валидацию запроса
- если данные не верны - отправляем ошибку клиенту
- если данные верны, то мы делаем две вещи. Во-первых назначаем уникальный GUID для пригедшего сообщения, а затем ставим его в очередь на обработку и отправляем обратно клиенту сформированный объект "Новость", как будто он уже записался в БД.
В результати такой махинации клиент сразу видит результат своих действий - отправленную новость или ошибку, а за счет наличия в ней уникального ID, который позже запишется в БД, он может начать делать какие-то манипуляции с этим объектом, еще до записи его в БД. 
Например, если он поставит Like для своей новости, то произойдет аналогичная ситуация:
- в очередь на обработку будет поставлена команда Like
- клиент сразу увидит результат своих действий

Что дальше. После того как сообщение взято на обработку Worker Role, оно инициирует изменнения в основной базе SQL, в которой хранятся все данные системы в удобном для запросов, поиска и хранения формате. 
Как только запись прошла, формируется объект из подготовленных для отображения данных (Новость, со вставленными ФИО автора, сокращенным и полным текстом, числом лайков и пр.) и она помещается в кеш-базу Redis. Более того, WorkerRole обновит в Redis персональные списки новостей, чтобы клиент не выбирал каждый раз новости, которые предназначены именно для него.
И теперь, если придет новый клиент и захочет посмотреть ленту сообщений он моментально получит списко причитающихся мне новостей и считает подготовленные для него объекты прямо из Redis, не мучая SQL.

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

Так что Microsoft Azure сейчас позволяет без глубоких полняний в устройстве сервисов, без лишнего ковыряния создавать высокопроизводительные веб-сервисы штатными средствами.

Восстановление пароля для PFX/P12/PKCS12 контейнера

Забыв очередной раз вариацию пароля для PFX-файла для Пуш-уведомлений полез в студенческие лабораторки и выковорил небольшую софтинку для восстановления паролей для PFX/PKCS12 контейнеров.
Восстанавливает она их прямым перебором.
Понятно что способ подойдет только если пароль небольшой и Вы примерно знаете где искать, но этого, обычно, бывает достаточно. 
Программка собрана на .NET 4.5 в Visual Studio 2013 и доступна с исходными кодами

Суть работы приложения на этом скриншоте:


PFXPasswordRecovery.zip (64,3KB)

KnockoutJS, SignalR в приложении ASP.NET MVC

Собирая внутрениие презентации для разработчиков по тех-решениям внашей платфомре Pryaniky.com, наткнулся на мою краткую илюстрацию работы нашего UI.
Построен он у нас на базе замечательной библиотеки KnockoutJS (http://knockoutjs.com/), позволяющей отвязать логику, данные и их отображение на странице. 
Еще одна используемая у нас библиотека - SignalR. Ключевая ее задача - получать данные в реальном времени, а также оповещ��ть клиентов об изменениях. С помощью нее мы формируем "Живую ленту" с постоянными обновлениями. Нединамические данные получаются как и раньше через ajax.
Появнить как это может совместно работать модно 1 слайдом:



Что имеем:
Есть некая модель страницы. Фактически класс AllPageModel
В нем для SignalR регистрируем обработчики сообщений (клиентские методы). Например Notify (строка this.hub.client.Notify регистрирует функцию).

С помощью синтаксиса Knockout мы можем связать даные модели (и методы, кстати), с элементами UI. Например, data-bind="click:postData" - связывает событие "Click" по элементу формы с вызовом метода postData.
А внутри метода postData мы с помощью ajax или SignalR можем обращаемся к серверу. 
В данном примере мы вызываем SignalR-метод и в нем тут же дергаем клиента, передавая ему сообщение "OK".

Если интересно подробнее посомтреть какие еще инструменты мы испольуем в Пряниках - в аттаче презентация :)


Knockout_and_SignalR.pdf (581,8KB)