Рубрика «смарт-карты»

Введение

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

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

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

SmartCard I2C Protocol. Обмен APDU командами через I2C интерфейс - 1
Читать полностью »

Герои двухфакторной аутентификации, или как «походить в чужих ботинках» - 1

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

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

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

Под катом мы расскажем как попытались представить себя на месте лиц принимающих решение о внедрении 2FA в организации, и поняли как их заинтересовать.
Читать полностью »

Варианты хранения криптографических ключей - 1Продолжает расти популярность решений на основе PKI — всё больше сайтов переходят на HTTPS, предприятия внедряют цифровые сертификаты для аутентификации пользователей и компьютеров, S/MIME доказывает свою состоятельность и для шифрования электронной почты, и как способ проверки источника сообщений для противодействия фишингу. Но шифрование и аутентификация в этих приложениях практически бессмысленны без правильного управления ключами.

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

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

В этой статье мы обсудим варианты защиты и хранения закрытых ключей. Как вы увидите, эти варианты могут незначительно отличаться в зависимости от типа сертификата(ов) и от того, как вы его используете (например, рекомендации для сертификатов SSL/TLS отличаются от рекомендаций для сертификатов конечных пользователей).
Читать полностью »

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

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

Результат всегда один. А вот транзакционная цепочка менялась от десятилетия к десятилетию. Менялось количество участников в процессе инициации и одобрения платежа. Тут стоит упомянуть слово «процессинг» не просто как обработку данных, а как процесс между инициацией транзакции и ее финалом (одобрение/отказ).
Читать полностью »

Карта тройка

Карта Тройка представляет из себя универсальный пополняемый электронный кошелек, широко используемый в системах оплаты общественного транспорта Москвы с 2013 года.

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

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

Итогом исследования стала разработка приложения TroikaDumper, позволяющего эксплуатировать уязвимости системы электронного кошелька.
Читать полностью »

imageВ последнее время меня часто спрашивают, что случилось с ключами eToken и почему их перестали продавать. Так же наблюдается некоторая паника по этому поводу, ввиду того, что большинство мировых вендоров поддерживает данные ключи в своих продуктах, а заменить их, получается нечем.

Отставить панику!

Ключи eToken никуда не исчезли, они продолжают выпускаться и продаваться на российском рынке. Да, они поменяли своё название и немного по-другому выглядят, но это всё те же eToken.
Читать полностью »

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

Мы подготовили понятный ответ на непростой вопрос о том, как устроены бесконтактные платежи. Для этого мы анимировали технологический процесс выпуска карты и проведения платежа в торговой точке. Посмотрите, как это выглядит для разных видов бесконтактных платежных средств: обычной пластиковой карты, телефона c NFC-антенной и специальным чипом безопасности (Secure Element) или для телефона с NFC-антенной и без чипа безопасности, но с поддержкой технологии «облачных» платежей.
Читать полностью »

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

Итак, смарт-карта на основе JavaCard — это карта, на которой приложения исполняются на JavaCard Virtual Machine (ограниченная версия Java Virtual Machine, адаптированная для смарт-карт) в так называемом JavaCard Runtime Environment (который с Java Runtime Environment имеет очень мало общего).

Что касается терминологии, то приложения называются Applets и содержатся в Packages (пакетах). Пакеты распространяются в CAP-files (вместо Jar-files). Пакеты и приложения имеют собственный AID (Application Identifier). Это необходимо для того, чтобы их можно было однозначно идентифицировать в таких командах, как: SELECT, INSTALL, DELETE, и т.д. (SELECT описывается в ISO7816-4, а JavaCard и остальные команды — в Global Platform).

Жизненный цикл Applets несколько отличается от привычного жизненного цикла приложений для компьютеров. Applet — это любой класс, наследующий от базового класса «Applet». При установке приложений вызывается его статический метод install. Этот метод должен создать объект соответствующего класса и вызвать на него метод register. Впоследствии объект будет сохранен в системе и получит собственный AID, который будет использован для дальнейшего общения с приложением. Объект и его поля данных сохраняются в NVM (Non-Volatile Memory). Каждый объект или массив, созданный приложением с помощью оператора «new», также будет находиться в NVM. Это означает, что, в отличие от традиционных компьютерных программ, состояние приложений JavaCard является постоянным и не теряется даже при выключении карты.
Читать полностью »

В прошлой части мы видели как происходит общение между терминалом и картой. Мы посмотрели форматы C-APDU и R-APDU, но мы не обращали внимания на то, какие данные содержат эти APDU. В этой части мы рассмотрим самые распространенные форматы, в которых передается информация между терминалом и картой (и наоборот). Все они относятся к одному семейству — TLV.

TLV означает Tag, Length, Value и используется для того, чтобы структурировать информацию. На очень абстрактном уровне, TLV можно рассматривать как бинарную версию XML. Однако что такое Tag, Length, Value?

  • Tag: он говорит, какой вид информации находится в TLV. Видом может быть, к примеру, простая строка или номер, идентификатор или даже сложная структура. В некоторых вариантах Tag также содержит мета-информацию о TLV.
  • Length: длина, в байтах, элемента Value.
  • Value: данные, содержащиеся в TLV

Каждый вариант TLV имеет свои правила кодирования каждого элемента. Далее мы посмотрим самые распространенные варианты TLV. Хочу сразу отметить, что данная статья будет, в основном, посвящена BER-TLV, поскольку это самый распространенный, гибкий и сложный формат. Остальные варианты TLV будут рассмотрены лишь вкратце.
Читать полностью »

Привет Гиктаймс!

После общей информации, описанной в первой части, сегодня поговорим об APDU в формате, описанном в стандарте ISO7816-4.

APDU (application protocol data unit) — это формат общения карты и терминала. Терминал посылает Command APDU (C-APDU), а карта отвечает с Response APDU (R-APDU).

C-APDU

Формат C-APDU таков:

Header Body
CLA INS P1 P2 [Lc field] [Data field] [Le field]

Каждый элемент заголовка (header) сохранен на одном байте и является обязательным. К заголовку вернемся чуть позже, сейчас поговорим о body команды.

Элементы body следующие:

  • Lc: длина элемента Data в байтах.
  • Data: данные команды.
  • Le: ожидаемая длина данных ответа в байтах, исключая длину Status Word.

Lc и Le, если присутствуют, могут занимать 1 (Short Length) или 3 байта (Extended Length) каждый. При Short Length кодируются значения от 1 до 256. Длина данных на 256 байтов записывается как «00». При Extended Length кодируются значения от 1 до 65536. Первый байт всегда «00» и остальные 2 байта — номер в формате Big Endian. Когда Lc или Le — «00 00 00», то длина данных — 65536 байтов.

В зависимости от присутствия или отсутствия элементы body команды можно разделить на 4 категории:

  • Case 1: Body полностью отсутсвует, то есть команда не содержит в себе никаких данных и не ожидается получение каких либо данных от карты при ответе.
  • Case 2: В body присутствует только Le, то есть команда не содержит в себе никаких данных, но при этом ожидается получение данных от карты.
  • Case 3: В body присутствуют Lc и Data, то есть команда содержит в себе данные, но при этом не ожидается получение данных от карты.
  • Case 4: В body присутствуют все элементы, а значит команда содержит в себе данные и ожидается получение данных от карты.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js