Содержание

Смарт-карты. Часть 4. JavaCard / Хабр

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

Сегодня я бы хотел поговорить о 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 является постоянным и не теряется даже при выключении карты.

Общение с приложением
В любой момент на каждом открытом логическом канале есть одно активное приложение. Активное приложение — это то приложение, которое получает все APDU, посылаемые терминалом. При получении APDU JavaCard вызывает метод process активного приложения, который берет полученный APDU как единственный параметр. Именно этот метод является ядром Applet, поскольку там обрабатываются запросы от терминала. Полученный объект APDU также используется для того, чтобы посылать ответы.

Applet может быть активирован двумя способами:

  • при reset карты или при открытии логического канала система, как правило, активирует то приложение, которое отмечено как Default Application
  • с помощью команды SELECT с P1 = 0x04 и AID (полный или частичный) приложения в Data
Когда приложение активируется с помощью команды SELECT, то сразу после активизации будет вызван метод process с APDU, содержащим данную команду. Таким образом Applet имеет возможность посылать информацию в ответ на команду SELECT при активизации.
Класс Applet предоставляет метод selectingApplet() для того, чтобы определить, если полученная команда вызвала активизацию приложения.

Приложение также имеет возможность переписать методы select() и deselect(), чтобы, соотвественно, провести инициализацию при активизации и де-инициализацию при де-активизации. Эти методы будут вызваны вне зависимости от того, каким образом было активировано приложение.

Логические каналы можно открывать и закрывать с помощью команды MANAGE CHANNEL. По открытым логическим каналам можно посылать любые команды, в том числе SELECT. Именно SELECT и MANAGE CHANNEL являются единственными командами, которые обрабатываются напрямую системой, а не активным приложением. Хотя в случае команды SELECT можно сказать, что она обрабатывается и системой, и активным приложением.

Полные правила активизации приложения и обработки команды SELECT довольно сложные, и существуют маленькие противоречия между JavaCard и Global Platform. Тем не менее, я затрону данную тему в одной из моих следующих статей. Сейчас стоит сказать, что карты зачастую следуют правилам, описанным в Global Platform.

Управление памятью
Как я уже сказал выше объекты и массивы по умолчанию сохраняются в NVM. Помимо NVM, JavaCard также дает возможность создать массивы в RAM с помощью ряда методов из класса JCSystem. При этом существуют 2 вида временной памяти: Clear on Reset и Clear on Deselect. Первая стирается при выключении или reset карты. Вторая стирается тогда, когда Applet перестает быть активным (т.е: при SELECT другого приложения, выключении, reset, и т.д.). Стоит отметить, что, хотя содержание массива стирается (т.е. там пишутся все нули или false), сам массив остается, и его можно, к примеру, сохранять в поле данных объекта.

Что сохраняется в NVM:

  • Все объекты и их поля данных.
  • Все массивы.
  • Содержание массивов, созданных оператором new.
Что сохраняется в RAM (CLEAR_ON_RESET либо CLEAR_ON_DESELECT):

  • Содержание массивов, созданных функциями JCSystem. makeTransient<тип>Array. Важно отметить, что объекты, находящиеся в массиве, созданном функцией JCSystem.makeTransientObjectArray(), все же будут сохраняться в NVM. Только ссылка на них будет в RAM.
  • Global Arrays: системные (APDU буфер и Install Parameters буфер), а также Global Arrays, созданные с помощью JCSystem.makeGlobalArray().
  • Буфер для транзакций. Однако прямой доступ к этому буферу невозможен.

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

1) Желание гарантировать, что при успешной установке приложения, оно не перестанет работать, если какое-то другое приложение взяло себе всю свободную память.
2) Сборщик мусора — необязательная (хоть и очень распространенная) функция. Это означает, что при динамическом создании обьектов существует риск, что созданные объекты никогда не будут удаляться. Со временем это приведет к отсутствию свободной памяти.

Даже в случае присутствия сборщика мусора, эта процедура происходит не автоматически, а по запросу приложения (JCSystem.requestObjectDeletion()).

Впоследствии код приложения редко получается «чистым» по параметрам объектно-ориентрованного программирования. Использование общего byte[] для множества различных операций — очень распространенная практика. Классы, состоящие исключительно из статических методов и работающие на byte[], тоже не редкость. К тому же, создание классов и объектов сводится к минимуму. Памяти мало и ее нужно беречь любой ценой.

Стоит также отметить роль объекта APDU. Его буфер, находящийся в RAM, стирается перед получением каждой команды. Его принято использовать не только для формирования ответа, но часто даже как временный буфер. Его размер — как минимум, 256 байтов или намного больше, если карта поддерживает Extended Length.

Applet Firewall
Важной чертой JavaCard, которая может путать программистов, является присутствие так называемого Applet Firewall. Цель Firewall — это не допускать, чтобы какой-либо Applet имел доступ к данным иного. Сразу скажу, что JavaCard допускает общение между приложениями с помощью Shareable Interfaces, а также чтобы пакеты являлись библиотеками классов и функций, которые могут быть использованы в разных приложениях. Именно поэтому возникает необходимость firewall. Основные принципы Applet Firewall следующие:

  • Каждое приложение принадлежит одному контексту. Все приложения из одного пакета принадлежат одному и тому же контексту.
  • Каждый объект принадлежит одному приложению или системе.
  • У пакета без приложений (библиотеки) нет контекста. Объекты из его классов принадлежат приложению, которое их создало.
  • В системе всегда есть один активный контекст.
  • Доступ (чтение/написание в случае массива и вызов методов в случае объекта) разрешается только к объектам, принадлежащим активному контексту.
  • Система имеет доступ ко всем объектам.
  • Вызов статических методов всегда разрешается и исполняется в активном контексте. Доступ к статическим полям данных тоже разрешается. Однако объекты, на которые ссылаются статические поля, следуют общим правилам firewall.
  • Временные массивы из типа CLEAR_ON_DESELECT доступны только тогда, когда активный контекст соответствует контексту активного приложения.
С помощью Shareable Interface программист может позволить определенным методам одного объекта быть доступными приложениям из другого контекста. Когда один из этих методов вызван, то система переключает контекст на тот контекст, которому принадлежит объект, предоставляющий Shareable Interface. Это означает, что данный метод имеет доступ только к объектам, принадлежащим его контексту, и если, к примеру, передать этому методу byte[] как параметр из оригинального контекста, то при доступе произойдет ошибка. После завершения исполнения метода контекст переключается обратно на изначальный.

Приложение также имеет доступ к определенным объектам, принадлежащим системе. Такие объекты называются Entry Points. Существуют два вида Entry Points: временные и постоянные. Постоянные Entry Points — простые, доступ к ним разрешен с любого контекста. Примером этому являются объекты из класса AID. Временные Entry Points, напротив, имеют ограничение, не позволяющее сохранять ссылки на них в полях данных объекта или статических полях класса. Пример временного Entry Point — объект APDU.

Начиная с JavaCard 3.0.4, существует также возможность создавать Global Arrays с помощью метода JCSystem.makeGlobalArray(). Их поведение точно такое же, как и у временных Entry Points. Они преимущественно нужны в качестве параметра для методов, вызванных по технике Shareable Interface.

Атомарность и транзакции
JavaCard гарантирует атомарные операции при изменении полей данных объектов или классов. Атомарность также обеспечена методами, работающими над массивами (кроме тех, которые имеют суффикс NonAtomic в названии). Это означает, что, к примеру, Util.arrayCopy либо скопирует все байты (при успешном исполнении), либо оставит массив неизменным в случае ошибки или потери энергии.

Если необходимо провести изменение в нескольких постоянных полях и массивах в одной атомарной операции, то JavaCard также предоставляет функции JCSystem.beginTransaction() для начала транзакции и JCSystem.commitTransaction() для ее завершения. Все изменения, происходящие в массивах и постоянных полях между вызовами JCSystem.beginTransaction() и JCSystem.commitTransaction(), автоматически будут являться частью транзакции. Если транзакция отменяется из-за ошибки, потери энергии или вызова метода JCSystem.abortTransaction(), то система восстановит изначальное состояние. Стоит запомнить, что техническая реализация транзакции использует дополнительный системный буфер. Если буфер заполняется полностью, то система дает ошибку TransactionException.

RMI
JavaCard поддерживает технологию RMI (Remote Metod Invocation). В этой статье я не буду освящать данную технологию. Скажу лишь только, что данная функциональность не является распространенной, и многие карты не поддерживают ее.

API
Большая часть JavaCard API посвящена криптографии. Есть классы для шифрования, создания и проверки цифровой подписи, генерирования ключей и случайных чисел, расчета контрольных сумм и хешов, а также для реализации схем обмена ключами. Помимо криптографии JavaCard также предоставляет классы для сохранения и проверки PIN и даже биометрических данных. Остальные классы предоставляют доступ к функциональности, описанной в других главах или являются вспомогательными для работы со строковыми, номерами, TLV и т.д. Что касается API, то он будет трактоваться в другой серии статей.

Основные ограничения JavaCard по сравнению с Java
Язык программирования приложений JavaCard — это Java. Почти Java. Так, типы char, float, double, long и enum не поддерживаются. Тип int является необязательным для карт (обычно современные карты его поддерживают) и его использование, если его не активировать соответствующей опцией, приведет к ошибке при конвертации приложения в CAP-file. Забудьте о for, итератор и lambda. Generics, статические import и аннотации (только Runtime Invisible) поддерживаются конвертером, начиная с версии 3.0.0, т.к. они не влияют на исполнение кода.

Для компилирования кода используется обыкновенный компилятор от JDK. Ошибки несовместимости будут заметны только при конвертации в CAP-file или при использовании умного IDE для JavaCard.

Самая большая проблема для программистов, на самом деле, — отсутствие int по умолчанию. Обычно они, действительно, не нужны, поэтому не хочется их активировать без надобности. Однако компилятор Java имеет привычку автоматически приводить результат всех арифметических операций к типу int. Для избежания этого в коде приходится использовать явное приведение типа к short или byte, что делает код менее читаемым.

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

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

Java Card

Java Card

Java Card

Назад  СодержаниеВперед

ЧТО ТАКОЕ JAVA CARD?

Java Card — это смарт-карта, способная выполнять программы на Java. Спецификация Java Card 2.0 опубликована на Web-узле http://www.javasoft.com/javacard. Там содержится подробная информация о способах построения виртуальной машины Java Card и прикладного программного интерфейса (API) смарт-карт. Минимальные системные требования — наличие 16 Кбайт памяти ROM (read-only memory), 8 Кбайт EEPROM и 256 байт RAM (random access memory).


Рис. 3. Архитектура Java Card

Системная архитектура Java Card представлена на рис. 3, из которого видно, что виртуальная машина Java Card находится на более верхнем уровне по сравнению со встроенной операционной системой и функциями специализированных интегральных схем (integrated circuit, IC). Уровень JVM скрывает технологические решения производителя за общим языком и системным интерфейсом. Структура Java Card определяет набор классов прикладного программного интерфейса (API), предназначенного для разработки приложений Java Card, и набор системных служб для нормального функционирования этих приложений. Необходимость дополнительных библиотек, которые реализуют расширенные служебные функции, обеспечивающие безопасность и описывающие системную модель, определяется спецификой решаемых задач. Приложения Java Card называются апплетами. На одной карте может выполняться несколько различных апплетов. Каждый апплет однозначно определяется идентификатором приложения (application identifier, AID), который описывается в пятой части стандарта ISO 7816.

Следует помнить об основных ограничениях смарт-карт. Нельзя приравнивать их к персональным компьютерам. Объем памяти и вычислительная мощность смарт-карт крайне малы, а Java Card 2.0 — это не просто урезанная версия JDK, а весьма специализированный продукт.

СРОК СЛУЖБЫ JAVA CARD

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

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

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

Итак, Java Card готова к применению. Ее можно приобрести непосредственно у эмитента или у другого продавца. Карты, распространяемые независимыми продавцами, называются картами общего назначения процесс персонализации у них, как правило, отсутствует.

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

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

СРОК СЛУЖБЫ ВИРТУАЛЬНОЙ МАШИНЫ JAVA CARD

В отличие от виртуальной машины Java (JVM), функционирующей на ПК или рабочей станции, виртуальная машина Java Card постоянно находится в активном состоянии.

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

СРОК СЛУЖБЫ АППЛЕТОВ И ОБЪЕКТОВ JAVA CARD

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

Объекты создаются в постоянной памяти (например, в EEPROM). Они могут быть потеряны или удалены механизмом «сборки мусора», если на них не ссылаются другие постоянные объекты. Однако запись в EEPROM выполняется на три порядка медленнее по сравнению с записью в RAM.

Доступ к некоторым объектам осуществляется достаточно часто, и содержимое их полей не нужно сохранять в неизменном состоянии. Java Card поддерживает временные (temporary) объекты, хранящиеся в памяти RAM. Если объект объявлен временным, его содержимое не может размещаться в постоянной памяти.

ПОДМНОЖЕСТВО ЯЗЫКА JAVA CARD 2.0

Программы для Java Card, естественно, пишутся на языке Java и компилируются с использованием стандартных компиляторов Java. Однако вследствие ограниченных ресурсов памяти и малой вычислительной мощности не все возможности, описанные в спецификации языка Java, могут быть реализованы в Java Card. В частности, Java Card не обеспечивает:
  • динамическую загрузку классов;
  • диспетчер безопасности;
  • потоки и синхронизацию;
  • клонирование объектов;
  • большинство примитивных типов данных (float, double, long и char).

    •  

     
     
     
     
     
     
     
     
     

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

    ПЛАТФОРМА JAVA CARD 2.0

    Смарт-карты существуют уже около 20 лет, и большинство из них совместимы со стандартами ISO 7816 (части 1-7) или EMV. Стандарт ISO 7816 мы уже рассмотрели. А что представляет собой EMV? EMV, совместимый с Europay, MasterCard и Visa, базируется на стандарте ISO 7816 и обладает дополнительными возможностями поддержки финансовой отрасли. Для обеспечения работы со смарт-картами и приложений была создана платформа Java Card Framework. Она скрывает детали инфраструктуры смарт-карт и предлагает производителям приложений для Java Card относительно простой и открытый программный интерфейс.

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

    БЕЗОПАСНОСТЬ JAVA CARD

    Действие апплетов Java Card ограничивается системой безопасности Java, однако модель безопасности Java Card существенно отличается от стандартной модели, принятой в Java. Java Card не поддерживает класс диспетчера безопасности (Security Manager). Политика безопасности реализуется средствами виртуальной машины.

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

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

    ПРИНЦИПЫ ВЗАИМОДЕЙСТВИЯ ОСНОВНЫХ КОМПОНЕНТОВ JAVA CARD

    Среда выполнения Java Card (Java Card Runtime Environment, JCRE) взаимодействует с виртуальной машиной Java Card и классами Java Card Framework. Каждому апплету Java Card соответствует уникальный идентификатор AID, назначаемый JCRE.

    После загрузки апплета в постоянную память карты и установления его связей с Java Card Framework и другими библиотеками начинается последний этап настройки. Общедоступный статический метод установки реализуется классом апплета, он предназначен для создания экземпляра программы и его регистрации в среде JCRE. Поскольку объем памяти карты ограничен, хорошим решением является создание и инициализация объектов на время работы апплета.

    Апплет, хранящийся в памяти карты, остается в неактивном состоянии до тех пор, пока он не будет явно запущен на выполнение. Терминал посылает среде JCRE команду «SELECT APDU». Среда JCRE приостанавливает выполнение активного апплета, вызывает метод завершения его работы и при необходимости очищает память. Затем JCRE помечает апплет, идентификатор AID которого совпадает с идентификатором, заданным в команде «SELECT APDU», и вызывает метод запуска этого апплета на выполнение. Метод запуска координирует проведение необходимых подготовительных операций. Среда JCRE переадресует команды APDU активному апплету до тех пор, пока не будет получена очередная команда «SELECT APDU».

    ЗАКЛЮЧЕНИЕ

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

    Платформа Java Card 2.0

    javacard.framework

    Это базовый пакет карты. Он определяет классы Applet и PIN, служащие для построения основных блоков программ Java Card и команд APDU, операционной системы и утилит, обеспечивающих реализацию сервисных функций Java Card, таких как управление командами APDU и совместное использование объектов.

    javacardx.framework

    Этот пакет предлагает объектно-ориентированную архитектуру файловой системы, совместимой со стандартом ISO 7816-4. Он поддерживает элементарные файлы (elementary files, EF), выделенные файлы (dedicated files, DF), а также ориентированные на работу с файлами команды APDU, определенные в стандарте ISO 7816.

    javacardx.crypto и javacardx.cryptoEnc

    Эти два пакета реализуют криптографические возможности, поддерживаемые смарт-картами.

    Назад  СодержаниеВперед

    Технология Java Card | Оракул

      Сожалеем. Мы не смогли найти совпадение по вашему запросу.

      Мы предлагаем вам попробовать следующее, чтобы найти то, что вы ищете:

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

      Связаться с отделом продаж

      Меню Меню

      загрузки Oracle Java Card

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

      Узнайте, как начать работу с технологией Oracle Java Card

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

      Начало работы

      Веб-семинар по строгой аутентификации пользователей

      Узнайте больше о строгой аутентификации пользователей с помощью технологии Oracle Java Card.

      Смотреть по запросу (1:11:42)

      Спецификации технологии Java Card 3.2

      Выпуск 3. 2 спецификаций технологии Java Card содержит различные усовершенствования, такие как поддержка протоколов (D)TLS1.3. Этот последний выпуск также включает разъяснения API, чтобы помочь разработчикам приложений и значительно повысить уровень взаимодействия между несколькими реализациями. Это ссылка на новые продукты технологии Java Card.

      Технология Oracle Java Card

      Технология Oracle Java Card обеспечивает возможность программирования встроенных устройств для конкретных приложений. Некоторые из многих вариантов использования включают SIM-карты и встроенные SIM-карты в телекоммуникациях, мобильные платежи NFC и потребности в безопасной идентификации, такие как паспорта.

      Инструменты комплекта разработки для карт Java Card Комплект для разработки карт Java SimulatorProtection Profile

      Инструменты Oracle для приложений технологии Oracle Java Card

      Инструменты комплекта разработки для технологии Oracle Java Card используются для преобразования и проверки приложений Java Card. Эти инструменты можно использовать с продуктами, основанными на версиях 3.1, 3.0.5 и 3.0.4 спецификаций Java Card.

      • Инструменты технологии Oracle Java Card Примечания к выпуску
      • загрузок пакета разработки Oracle Java Card

      Симулятор технологии Oracle Java Card

      Симулятор комплекта разработки Java Card предлагает справочник по тестированию и отладке приложений Java Card. Он включает в себя среду моделирования Java Card и подключаемый модуль Eclipse. Он обеспечивает поддержку последней спецификации Java Card 3.1, а также может запускать приложения, написанные для более ранних выпусков.

      • Примечания к выпуску симулятора технологии Oracle Java Card
      • загрузок пакета разработки Oracle Java Card

      Профиль защиты для открытых и закрытых конфигураций для технологии Oracle Java Card

      Чтобы удовлетворить требования банков, правительств и других организаций по оценке безопасности, профиль защиты Java Card предоставляет модульный набор требований безопасности, разработанный специально для характеристики технологии Oracle Java Card.

      • Профиль защиты открытой конфигурации Java Card (0099)
      • Профиль защиты закрытой конфигурации Java Card (0101)

      Безопасность и мобильность с картой Java Card

      • Устройство ввода-вывода Java Card для защиты периферийных устройств на шине I3C

        Используйте карту Java Card на защищенном элементе устройства IoT для защиты доступа к периферийным устройствам на шине I3C.

        Узнайте больше о вводе-выводе устройства Java Card (1:11:42)

      • Многооблачная аутентификация с помощью Java Card 3.1

        Безопасная связь между устройствами IoT и облачными службами IoT с использованием карты Java.

        Узнайте больше о многооблачной аутентификации (38:57)

      • Демонстрация строгой аутентификации пользователей с использованием карты Java Card и FIDO

        Аутентификация без пароля с использованием биометрии на основе спецификации FIDO с картой Java Card и Oracle Identity Cloud Service.

        Узнайте больше об аутентификации пользователей (1:11:42)

      30 января 2023 г.

      Объявление о выпуске Java Card Release 3.2

      Николя Понсини, архитектор решений безопасности Java, Oracle

      Как и любой новый выпуск Java Card, этот последний выпуск Java Card содержит улучшения, такие как поддержка протоколов (D)TLS1.3 и API разъяснения, которые помогут разработчикам приложений и значительно повысят уровень взаимодействия между несколькими реализациями.

      Прочитать сообщение полностью

      Избранные блоги
      • 30 ОКТЯБРЯ 2020 ГОДА Серия вебинаров Java Card Forum 2020: зачем использовать технологию Java Card в секторе IoT?
      • 20 июля 2020 г. Java Card 3.1 изучена
      • 09 ЯНВАРЯ 2020 ГОДА Семинар Oracle и GlobalPlatform SE IoT в Нюрнберге, февраль 2020 г.
      • 10 ОКТЯБРЯ 2019 ГОДА Провидец
      • 10 СЕНТЯБРЯ 2019 ГОДА Пограничные вычисления на SIM-карте с Java Card 3. 1
      Посмотреть все

      Ресурсы карты Java

      ДокументацияТехнические ресурсыFAQМатериалы по теме

      Технические ресурсы
      • Загрузки
      • Предыдущий выпуск
      • Лист данных (PDF)
      • Технические описания (PDF)
      • Другие технические ресурсы (PDF)
      Связанный контент
      • Форум Java Card

      Начало работы с Java Card

      Инструменты Java Card и эталонная реализация

      Ознакомьтесь с инструментами Java Card Development Kit и эталонной реализацией.

      Плагин Eclipse для карты Java Card

      Ознакомьтесь с подключаемым модулем Eclipse для разработки приложений Java Card.

      Разработка апплета HelloWorld

      Изучите основы разработки приложений Java Card.

      Свяжитесь с отделом продаж

      Получите информацию о том, как стать лицензиатом Java Card.

      Свяжитесь с нами

      Java Card — Технология — Thales

      Что такое Java Card?

      Java Card — это стандартная технологическая платформа, разработанная Sun Microsystems (теперь Oracle) для поддержки приложений на основе Java — апплеты — для запуска на смарт-картах , поддерживающих этот стандарт.

      Java Card 3.1 — это последняя версия, анонсированная Oracle в конце января 2019 года.

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

      Почему карта Java?

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

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

      Технология Java Card используется в широком спектре приложений смарт-карт, включая:

      • Карты Smart ID для логического и физического доступа к корпоративным ресурсам
      • Модули идентификации абонента, используемые в мобильных телефонах в беспроводных сетях
      • Модули идентификации машин, используемые в M2M и IoT 
      • Банковские карты EMV для традиционных и онлайн-банковских операций
      • Государственные удостоверения личности и медицинские карты.

      Есть еще.

      Карта Java теперь может обеспечивать доступ к сетям NBIoT или 5G.

      Преимущества карты Java Card

      Ее уникальные функции обеспечивают ряд преимуществ.

      • Апплеты являются интероперабельными и работают на любом устройстве со смарт-картой на базе Java Card, что снижает затраты на оборудование.
      • Кроме того, несколько приложений может находиться на одном устройстве.
      • Новые приложения можно безопасно установить после выпуска карты с помощью платформ беспроводной связи (OTA), что позволяет эмитентам карт динамически реагировать на изменяющиеся потребности своих клиентов.
        • Карты Java
      • обеспечивают простое и быстрое обновление благодаря открытой архитектуре ОС, которая отделяет платформу от приложения. Это разделение также снижает ограничения миграции даже после первоначального выпуска карты.

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

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

       

      , 

      Признанный открытый стандарт

      По данным Oracle, ежегодно выпускается около шести миллиардов устройств с поддержкой Java Card.

      Являясь открытым стандартом, поддерживаемым ведущими производителями смарт-карт, включая Thales, Java Card предлагает одну из самых безопасных доступных технологических платформ.

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

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

      Дополнительные ресурсы по Java Card

      • Страница Oracle по Java: http://www.

        No related posts.