веб-сервер в смарт-карте: уже реальность?
В это трудно поверить, но на рис.1 и 2 вы можете увидеть один из самых маленьких действующих веб-серверов в мире!
Рис. 1. Webcard.
Рис. 2. Общий вид системы.
WebCard — веб-сервер, работающий в смарт-карте Schlumberger Cyberflex Access Java Card. Карта запрограммирована производителем на реализацию виртуальной машины Java, понимающей некоторую часть языка Java. Карта может использоваться одновременно для разных целей, как описано в стандартах ISO 7816-4 и EMV 96. WebCard написан как Java-приложение, называемое апплетом (или кардлетом).
Карта доступа Cyberflex имеет 16 кб EEPROM и около 1.2 кб оперативной памяти. Эти ограниченные ресурсы сильно осложняют создание полноценного, соответствующего станадртам стека TCP/IP.
В качестве первого шага к созданию полноценного стека TCP/IP был реализован минимальный набор его функций. Первоначальной целью было создать сервер, который отвечает на правильный ввод и не «вылетает» при неправильном.
Спецификации HTTP, TCP и IP предъявляют много требований, многие из которых давно устарели или вообще никогда не использовались на практике. Для первой реализации были выбраны только те спецификации, которые необходимы для нормального функционирования. Для того, чтобы понять, какие возможности реально используются, а какие — нет, использовался tcpdump HTTP-транзакций между несколькими клиентами и сервером.
одновременно только одно подключение
Сервер Webcard упрощен за счет того, что предполагается, что в один момент времени будет активно только одно подключение. Это позволяет серверу сохранять статус подключения до того момента как придет следующий запрос. Это также отменяет необходимость рассчитывать тайм-аут для оборвавшихся соединений и отвечать на запросы о смене статуса. Тем не менее, многие веб-браузеры запускают запросы параллельно, поэтому сервер не должен возвращать страницы с контентом вроде картинок.
Смягчить данное ограничение не так уж и сложно. Состояния подключения, поддерживаемые Webcard — имя файла; состояние TCP (реально никогда не используется), TCP port — чтобы применить ограничение на одно подключение. Соединения могут быть разорваны по давности, с приходом нового запроса на подключение. За счет этого отпадает необходимость в таймере, которого нет в платформе Cyberflex Access.
HTTP
Сервер понимает протокол HTTP версии 1.0, который намного проще в реализации, чем версия 1.1 или более поздние. Более ранние версии HTTP, например, HTTP 0.9, не могут общаться с Webcard, но в настоящее время, клиенты, использующие ее, очень редки. Современные клиенты используют HTTP 1.1 или более поздний, который требует совместимости с HTTP 1.0.
Каждый запрос обрабатывается как индивидуальное TCP-соединение. Статусная строка HTTP, «HTTP/1.0 200 OK» сохранена вместе с документами, поэтому сервер не генерирует никаких заголовков и информации, кроме той, что находится в файле.
Запрос GET HTTP 1.0 состоит из имени метода «GET», за которым идет символ пробела и URL (Webcard не поддерживает никакие другие методы вроде HEAD, POST или PUT). На данный момент URL могут состоять из 3-х символов, 2 последние из которых обозначают имя файла (имена файлов по ISP 7816-4 должны быть двухбайтными).
Когда сервер получает запрос, он выбирает необходимый файл. Он не сохраняет никакого статуса, отражающего подлинность запрашиваемого файла. Это позволяет сделать только одно HTTP-соединение активным одновременно, как было описано выше.
TCP
Сервер не содержит никакой конфигурационной информации. Все входящие пакеты предполагаются адресованными серверу. При создании ответных пакетов, TCP-стек просто меняет местами адреса отправителя и получателя. При этом не требуется никакой информации по подсетям и маршрутизации. Webcard отбрасывает любые пакеты, не адресованные 80-у порту. Все опции TCP игнорируются.
Конечный автомат TCP имеет только 3 состояния: LISTEN, ESTABLISHED и FIN-WAIT-1. Он не способен инициировать соединение, и не имеет соответствующего состояния SYN-STATE. Также нет и состояния CLOSE.
Webcard сохраняет информацию о состояниях TCP, но никак ее не использует. Также он не выполняет повторной пересылки информации, что отменяет необходимость в таймерах (которые недоступны) и в сохранении информации о всех состояниях TCP. На практике TCP-пакеты довольно редко отбрасываются, поэтому данное ограничение не так уж и страшно. Конечный автомат отвечает на 4 типа пакетов. SYN вызывает ответ SYN ACK и перевод в состояние ESTABLISHED без ожидания ACK на SYN. Предполагается, что SYN ACK не потеряется по дороге. Это ограничение по сути ограничением и не является, так как в случае потери SYN ACK клиентом будет заново отправлен SYN, что позволит в конце-концов установить соединение.
HTTP 1.0 позволяет пересылать серверу только одну строку текста. Таким образом, любой пакет с данными воспринимается как завершенный запрос HTTP GET. URL Webcard имеют длину 3 байта. Предполагается, что 7 байт запроса GET URL приходят в одном, не фрагментированном TCP сегменте. Сервер извлекает URL из запроса и выбирает нужный файл в файловой системе ISO 7816-4. Если файл не существует, сервер выбирает файл «nf», который содержит сообщение «404 Not Found». Пакет данных извлекает ACK из последовательного номера последовательности клиента.
FIN вызывает ACK и переводит состояние конечного автомата TCP в LISTEN. HTTP-клиенты всегда ждут от сервера закрытия соединения, но тут нет состояния CLOSE-WAIT или LAST-ACK. Если клиент попытается преждевременно закрыть соединение, он будет ожидать FIN от Webcard и застрянет в состоянии FIN-WAIT-2 на неопределенное время. Однако большинство TCP-клиентов смогут самостоятельно выбраться из данной ситуации.
ACK без приложенной информации приводит к извлечению информации из выбранного файла. Механизм окон не реализован, поэтому информация отсылается только после того, как придет ACK на предыдущий сегмент. Номера последовательностей Webcard всегда начинаются с нуля, таким образом, номер ACK от клиента дает смещение внутри файла.
Webcard не проверяет клиентские контрольные суммы и игнорирует предлагаемое окно, флаг и указатель urgent и флаг push. Пакеты RST также игнорируются. Исходящие пакеты всегда предлагают маленькое окно фиксированного размера. Актуальный размер окна не важен — предполагается, что клиенту не потребуется отправлять больше 17 байт.
IP
Предполагается, что входящие пакеты не содержат опций IP. Игнорировать опции было бы не сложно, но на практике они и так почти никогда не используются. Заголовок IP checksum должен быть реализован в 16-битной арифметике, поскольку карта не поддерживает 32-битную.
MRU (входящий MTU) ограничен интерфейсом ISO - меньше чем 256 байтами. Webcard не поддерживает сборку IP, так как единственная важная информация — URL - находится в первых 17 байтах.
кардлет
Кардлеты Cyberflex содержат основной метод в дополнение к методам Java Card. Это позволяет им функционировать как отдельным программам. Правда, Webcard не использует данную возможность.
Кардлет должен содержать как минимум 3 метода: «install», «select» и «process». Метод «install» вызывается один раз во время инициализации карты. Он создает и инициализирует объекты, необходимые апплету. Метод «select» запускается при выборе кардлета, обычно через APDU (блок протокола выбора приложений). Кардлет может быть установлен по умолчанию для карты и автоматически выбираться каждый раз, когда она используется, вне зависимости от места использования.
Метод «process» выполняет всю основную работу. При передаче карте APDU, он передается методу «process» текущего выбранного кардлета. IP-пакеты передаются Webcard инкапсулированными в APDU. При сбросе, загрузчик Cyberflex Access ждет входящего APDU и передает его кардлету ip7816. Если APDU — пакет (INS=0x12), кардлет обрабатывает его; в противном случае он передается обратно загрузчику.
Webcard извлекает длину данных, порт назначения и некоторые другие поля из заголовков IP и TCP и входит в конечный автомат TCP. Затем он создает, если необходимо, пакет с ответом, опционально присоединяет к нему исходящую информацию, подсчитывает контрольные суммы TCP и IP и отправляет ответный пакет как исходящую информацию 7816. В нескольких точках данного процесса кардлет вызывает apdu.waitExtension() для передачи «холостого» сообщения 7816 карточному терминалу, чтобы в нем не наступил тайм-аут.
Кардлет Webcard занимает примерно 1200 байт Java-кода, оставляя примерно 14 кбайт на веб-контент.
управление картой
Контент загружается в карту при помощи SCFS — расширение CITI для ОС UNIX, монтирующее любую ISO 7816-4 файловую систему смарткарт в файл в пространстве имен UNIX.
Кадлеты могут быть написаны в любой среде разработки Java. Авторами сервера использовался стандартный UNIX-редактор и JDK от Sun Microsystems для компиляции в байт-код. Специализированная программа от Cyberflex — MakeSolo конвертирует файл классов в кардлет, готовый к загрузке с помощью другого инструмента из набора разработчика от Cyberflex.
интерфейс хоста
Карта доступа Cyberflex имеет интерфейс ISO 7816-3. Этот протокол использовался вместо более сложных SLIP или PPP. IP-пакеты инкапсулируются в APDU 7816 без каких-либо дополнительных заголовков. Максимальный размер APDU равен 256 байтам. Простой демон, запущенный на OpenBSD (или, при желании, на любой системе с туннелирующим устройством) перенаправляет пакеты к карте. Демон не поддерживает IP-фрагментацию и обрезает любой пакет, больший чем APDU.
Каждый входящий пакет вызывает как минимум один ответ. Cyberflex Access поддерживает протокол T=0 7816-3, поэтому пакет с ответом получается демоном с APDU «получен ответ».
Маршрутизация к карте требует внешнего объявления существования туннеля. В CITI Webcard был назначен IP-адрес из локальной подсети и прописан статический маршрут на маршрутизаторе подключения к интернет. На хосте, к которому подключен кардридер, была произведена конфигурация следующими командами:
# configure the tunnel
ifconfig tun0 141.211.169.2 smarty
# route through the tunnel
route add smarty 141.211.169.2
# start the tunnel daemon
ip7816d 141.211.169.2
физические характеристики
Физические размеры Webcard соответствуют ISO 7810 ID-1: 85.6 x 54 x .76 мм. Из них чип занимает 10 x 12 мм.
Производительность Webcard, составляющая 130 байт/с, конечно, не очень впечатляет. Планируется поднять ее за счет изменения кода после того, как будет достигнута более высокая функциональность.
Функциональность же планируется расширить во многих направлениях, но основное — это улучшение HTTP-, TCP- и IP-совместимости. Первая цель — поддержка таких важных вещей, как ICMP.
конкуренты
Еще один интересный проект — WebACE (рис. 3) — построен на базе микроконтроллера Fairchild ACE1101MT8, запрограммированного соответствующим образом и содержащего 2 маленькие веб-странички в своей набортной памяти.
Рис. 3. WebACE.
ACE1101 в 5 раз меньше предыдущего рекордсмена Microchip PIC12C509A/SN.
Веб-сервер использует специально разработанный стек TCP/IP с большим числом ограничений, но позволяющий обслуживать небольшие веб-страницы. Он подключен к Интернет с помощью стандартного SLIP-линка.
Представьте себе такой сервер, который, например, показывает текущую температуру в вашем морозильнике или что-либо еще.
Сервер также отвечает на PING.
железо
Компоненты, необходимые для работы сервера, занимают места не намного больше, чем сам чип и намного меньше, чем кабель последовательного интерфейса, подключенный к нему. Сервер состоит из микроконтроллера ACE1101, двух светодиодных индикаторов статуса, стабилизатора напряжения и нескольких дискретных элементов для интерфейса RS232.
Красный светодиод моргает, когда приходят пакеты, зеленый — контролируется ссылкой на домашней странице. SLIP-линк со скоростью 57,6 кбит/с соединяет сервер с Linux-хостом, который работает в режиме моста между SLIP и Ethernet LAN. Далее LAN подключается через NAT firewall и кабельный модем к Интернет.
Микроконтроллер был куплен в интернет-магазине всего за $2.12.
На рис. 4 приведена электронная схема сервера.
Рис. 4. — электрическая схема сервера.
Джим Ри, Питер Ханимен (Webcard); Фредерик Уайт (WebACE), перевод Дмитрия Герусса.
Рис. 1. Webcard.
Рис. 2. Общий вид системы.
WebCard — веб-сервер, работающий в смарт-карте Schlumberger Cyberflex Access Java Card. Карта запрограммирована производителем на реализацию виртуальной машины Java, понимающей некоторую часть языка Java. Карта может использоваться одновременно для разных целей, как описано в стандартах ISO 7816-4 и EMV 96. WebCard написан как Java-приложение, называемое апплетом (или кардлетом).
Карта доступа Cyberflex имеет 16 кб EEPROM и около 1.2 кб оперативной памяти. Эти ограниченные ресурсы сильно осложняют создание полноценного, соответствующего станадртам стека TCP/IP.
В качестве первого шага к созданию полноценного стека TCP/IP был реализован минимальный набор его функций. Первоначальной целью было создать сервер, который отвечает на правильный ввод и не «вылетает» при неправильном.
Спецификации HTTP, TCP и IP предъявляют много требований, многие из которых давно устарели или вообще никогда не использовались на практике. Для первой реализации были выбраны только те спецификации, которые необходимы для нормального функционирования. Для того, чтобы понять, какие возможности реально используются, а какие — нет, использовался tcpdump HTTP-транзакций между несколькими клиентами и сервером.
одновременно только одно подключение
Сервер Webcard упрощен за счет того, что предполагается, что в один момент времени будет активно только одно подключение. Это позволяет серверу сохранять статус подключения до того момента как придет следующий запрос. Это также отменяет необходимость рассчитывать тайм-аут для оборвавшихся соединений и отвечать на запросы о смене статуса. Тем не менее, многие веб-браузеры запускают запросы параллельно, поэтому сервер не должен возвращать страницы с контентом вроде картинок.
Смягчить данное ограничение не так уж и сложно. Состояния подключения, поддерживаемые Webcard — имя файла; состояние TCP (реально никогда не используется), TCP port — чтобы применить ограничение на одно подключение. Соединения могут быть разорваны по давности, с приходом нового запроса на подключение. За счет этого отпадает необходимость в таймере, которого нет в платформе Cyberflex Access.
HTTP
Сервер понимает протокол HTTP версии 1.0, который намного проще в реализации, чем версия 1.1 или более поздние. Более ранние версии HTTP, например, HTTP 0.9, не могут общаться с Webcard, но в настоящее время, клиенты, использующие ее, очень редки. Современные клиенты используют HTTP 1.1 или более поздний, который требует совместимости с HTTP 1.0.
Каждый запрос обрабатывается как индивидуальное TCP-соединение. Статусная строка HTTP, «HTTP/1.0 200 OK» сохранена вместе с документами, поэтому сервер не генерирует никаких заголовков и информации, кроме той, что находится в файле.
Запрос GET HTTP 1.0 состоит из имени метода «GET», за которым идет символ пробела и URL (Webcard не поддерживает никакие другие методы вроде HEAD, POST или PUT). На данный момент URL могут состоять из 3-х символов, 2 последние из которых обозначают имя файла (имена файлов по ISP 7816-4 должны быть двухбайтными).
Когда сервер получает запрос, он выбирает необходимый файл. Он не сохраняет никакого статуса, отражающего подлинность запрашиваемого файла. Это позволяет сделать только одно HTTP-соединение активным одновременно, как было описано выше.
TCP
Сервер не содержит никакой конфигурационной информации. Все входящие пакеты предполагаются адресованными серверу. При создании ответных пакетов, TCP-стек просто меняет местами адреса отправителя и получателя. При этом не требуется никакой информации по подсетям и маршрутизации. Webcard отбрасывает любые пакеты, не адресованные 80-у порту. Все опции TCP игнорируются.
Конечный автомат TCP имеет только 3 состояния: LISTEN, ESTABLISHED и FIN-WAIT-1. Он не способен инициировать соединение, и не имеет соответствующего состояния SYN-STATE. Также нет и состояния CLOSE.
Webcard сохраняет информацию о состояниях TCP, но никак ее не использует. Также он не выполняет повторной пересылки информации, что отменяет необходимость в таймерах (которые недоступны) и в сохранении информации о всех состояниях TCP. На практике TCP-пакеты довольно редко отбрасываются, поэтому данное ограничение не так уж и страшно. Конечный автомат отвечает на 4 типа пакетов. SYN вызывает ответ SYN ACK и перевод в состояние ESTABLISHED без ожидания ACK на SYN. Предполагается, что SYN ACK не потеряется по дороге. Это ограничение по сути ограничением и не является, так как в случае потери SYN ACK клиентом будет заново отправлен SYN, что позволит в конце-концов установить соединение.
HTTP 1.0 позволяет пересылать серверу только одну строку текста. Таким образом, любой пакет с данными воспринимается как завершенный запрос HTTP GET. URL Webcard имеют длину 3 байта. Предполагается, что 7 байт запроса GET URL приходят в одном, не фрагментированном TCP сегменте. Сервер извлекает URL из запроса и выбирает нужный файл в файловой системе ISO 7816-4. Если файл не существует, сервер выбирает файл «nf», который содержит сообщение «404 Not Found». Пакет данных извлекает ACK из последовательного номера последовательности клиента.
FIN вызывает ACK и переводит состояние конечного автомата TCP в LISTEN. HTTP-клиенты всегда ждут от сервера закрытия соединения, но тут нет состояния CLOSE-WAIT или LAST-ACK. Если клиент попытается преждевременно закрыть соединение, он будет ожидать FIN от Webcard и застрянет в состоянии FIN-WAIT-2 на неопределенное время. Однако большинство TCP-клиентов смогут самостоятельно выбраться из данной ситуации.
ACK без приложенной информации приводит к извлечению информации из выбранного файла. Механизм окон не реализован, поэтому информация отсылается только после того, как придет ACK на предыдущий сегмент. Номера последовательностей Webcard всегда начинаются с нуля, таким образом, номер ACK от клиента дает смещение внутри файла.
Webcard не проверяет клиентские контрольные суммы и игнорирует предлагаемое окно, флаг и указатель urgent и флаг push. Пакеты RST также игнорируются. Исходящие пакеты всегда предлагают маленькое окно фиксированного размера. Актуальный размер окна не важен — предполагается, что клиенту не потребуется отправлять больше 17 байт.
IP
Предполагается, что входящие пакеты не содержат опций IP. Игнорировать опции было бы не сложно, но на практике они и так почти никогда не используются. Заголовок IP checksum должен быть реализован в 16-битной арифметике, поскольку карта не поддерживает 32-битную.
MRU (входящий MTU) ограничен интерфейсом ISO - меньше чем 256 байтами. Webcard не поддерживает сборку IP, так как единственная важная информация — URL - находится в первых 17 байтах.
кардлет
Кардлеты Cyberflex содержат основной метод в дополнение к методам Java Card. Это позволяет им функционировать как отдельным программам. Правда, Webcard не использует данную возможность.
Кардлет должен содержать как минимум 3 метода: «install», «select» и «process». Метод «install» вызывается один раз во время инициализации карты. Он создает и инициализирует объекты, необходимые апплету. Метод «select» запускается при выборе кардлета, обычно через APDU (блок протокола выбора приложений). Кардлет может быть установлен по умолчанию для карты и автоматически выбираться каждый раз, когда она используется, вне зависимости от места использования.
Метод «process» выполняет всю основную работу. При передаче карте APDU, он передается методу «process» текущего выбранного кардлета. IP-пакеты передаются Webcard инкапсулированными в APDU. При сбросе, загрузчик Cyberflex Access ждет входящего APDU и передает его кардлету ip7816. Если APDU — пакет (INS=0x12), кардлет обрабатывает его; в противном случае он передается обратно загрузчику.
Webcard извлекает длину данных, порт назначения и некоторые другие поля из заголовков IP и TCP и входит в конечный автомат TCP. Затем он создает, если необходимо, пакет с ответом, опционально присоединяет к нему исходящую информацию, подсчитывает контрольные суммы TCP и IP и отправляет ответный пакет как исходящую информацию 7816. В нескольких точках данного процесса кардлет вызывает apdu.waitExtension() для передачи «холостого» сообщения 7816 карточному терминалу, чтобы в нем не наступил тайм-аут.
Кардлет Webcard занимает примерно 1200 байт Java-кода, оставляя примерно 14 кбайт на веб-контент.
управление картой
Контент загружается в карту при помощи SCFS — расширение CITI для ОС UNIX, монтирующее любую ISO 7816-4 файловую систему смарткарт в файл в пространстве имен UNIX.
Кадлеты могут быть написаны в любой среде разработки Java. Авторами сервера использовался стандартный UNIX-редактор и JDK от Sun Microsystems для компиляции в байт-код. Специализированная программа от Cyberflex — MakeSolo конвертирует файл классов в кардлет, готовый к загрузке с помощью другого инструмента из набора разработчика от Cyberflex.
интерфейс хоста
Карта доступа Cyberflex имеет интерфейс ISO 7816-3. Этот протокол использовался вместо более сложных SLIP или PPP. IP-пакеты инкапсулируются в APDU 7816 без каких-либо дополнительных заголовков. Максимальный размер APDU равен 256 байтам. Простой демон, запущенный на OpenBSD (или, при желании, на любой системе с туннелирующим устройством) перенаправляет пакеты к карте. Демон не поддерживает IP-фрагментацию и обрезает любой пакет, больший чем APDU.
Каждый входящий пакет вызывает как минимум один ответ. Cyberflex Access поддерживает протокол T=0 7816-3, поэтому пакет с ответом получается демоном с APDU «получен ответ».
Маршрутизация к карте требует внешнего объявления существования туннеля. В CITI Webcard был назначен IP-адрес из локальной подсети и прописан статический маршрут на маршрутизаторе подключения к интернет. На хосте, к которому подключен кардридер, была произведена конфигурация следующими командами:
# configure the tunnel
ifconfig tun0 141.211.169.2 smarty
# route through the tunnel
route add smarty 141.211.169.2
# start the tunnel daemon
ip7816d 141.211.169.2
физические характеристики
Физические размеры Webcard соответствуют ISO 7810 ID-1: 85.6 x 54 x .76 мм. Из них чип занимает 10 x 12 мм.
Производительность Webcard, составляющая 130 байт/с, конечно, не очень впечатляет. Планируется поднять ее за счет изменения кода после того, как будет достигнута более высокая функциональность.
Функциональность же планируется расширить во многих направлениях, но основное — это улучшение HTTP-, TCP- и IP-совместимости. Первая цель — поддержка таких важных вещей, как ICMP.
конкуренты
Еще один интересный проект — WebACE (рис. 3) — построен на базе микроконтроллера Fairchild ACE1101MT8, запрограммированного соответствующим образом и содержащего 2 маленькие веб-странички в своей набортной памяти.
Рис. 3. WebACE.
ACE1101 в 5 раз меньше предыдущего рекордсмена Microchip PIC12C509A/SN.
Веб-сервер использует специально разработанный стек TCP/IP с большим числом ограничений, но позволяющий обслуживать небольшие веб-страницы. Он подключен к Интернет с помощью стандартного SLIP-линка.
Представьте себе такой сервер, который, например, показывает текущую температуру в вашем морозильнике или что-либо еще.
Сервер также отвечает на PING.
железо
Компоненты, необходимые для работы сервера, занимают места не намного больше, чем сам чип и намного меньше, чем кабель последовательного интерфейса, подключенный к нему. Сервер состоит из микроконтроллера ACE1101, двух светодиодных индикаторов статуса, стабилизатора напряжения и нескольких дискретных элементов для интерфейса RS232.
Красный светодиод моргает, когда приходят пакеты, зеленый — контролируется ссылкой на домашней странице. SLIP-линк со скоростью 57,6 кбит/с соединяет сервер с Linux-хостом, который работает в режиме моста между SLIP и Ethernet LAN. Далее LAN подключается через NAT firewall и кабельный модем к Интернет.
Микроконтроллер был куплен в интернет-магазине всего за $2.12.
На рис. 4 приведена электронная схема сервера.
Рис. 4. — электрическая схема сервера.
Джим Ри, Питер Ханимен (Webcard); Фредерик Уайт (WebACE), перевод Дмитрия Герусса.
Сетевые решения. Статья была опубликована в номере 10 за 2005 год в рубрике лабораторная работа
