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

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

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

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

Технология CryptoCard позволяет исключить приведенные выше риски применения статических паролей. В любом решении на базе CryptoCard используется два компонента - программная часть (CRYPTOServer, ранее CryptoAdmin версий 5.32 и ниже) и аппаратная (интеллектуальный генератор пароля, или токен). В частном случае, функции токена может выполнять клиентский программный модуль (версии программных токенов имеются для большинства операционных систем, а также для PalmOS).

Сервис, парольную защиту которого, необходимо обеспечить по технологии CryptoCard должен иметь возможность проведения аутентификации и идентификации абонентов либо через непосредственное взаимодействие с CRYPTOServer, либо через сервер протоколов (Protocol Server) являющегося частью CRYPTOServer. Типичным и наиболее широко распространенным протоколом для решения задачи взаимодействия приложения (сервиса) и CRYPTOServer является RADIUS (Remote Authentication Dial In User Service).

В структуре решения CryptoCard можно выделить две основные стадии проведения аутентификации абонента - подготовительную и непосредственно аутентификацию.

На подготовительном этапе (который производится однажды при заведении абонента в системе) происходит инициализация токена в результате чего в него заносится персональный ключ владельца генератора. Одновременно с инициализацией генератору присваивается PIN-код для доступа непосредственно к генератору (как в SIM-карте мобильного телефона) и учетное имя. Такой же ключ (соответствующий данному PIN и учетному имени), как и в токене, хранится и в базе данных ключей CRYPTOServer.
Аппаратные токены инициализируются при помощи специальных устройств - инициализаторов, которые заносят в токен ключ и пр. служебные данные, тем самым активируя токен и разрешая его работу в системе. Для активизации программных токенов используется ключевая информация, единожды передаваемая владельцу программного токена на физическом носителе (USB Flash карта, SD карта, дискета, CD-диск и т.д.).

Основная процедура идентификации и аутентификации выглядит следующим образом: (1) пользователь в ответ на запрос об идентификации вводит логин своей учетной записи, который передается удаленной системе. После получения логина защищаемый сервис обращается к ресурсам CRYPTOServer для проверки существования абонента с указанным логином, и получает либо отказ в обслуживании AUTH-REJECT (в терминах RADIUS) если пользователя не существует либо случайное число, сгенерированное CRYPTOServer, которое (2) передается удаленному пользователю в виде строки символов.

Одновременно CRYPTOServer преобразовывает случайное число в соответствии с ключом, который принадлежит владельцу данного учетного имени (результат преобразования является сессионным паролем). Аналогичная операция преобразования происходит и в токене пользователя, куда сгенерированное случайное число (challenge) заносится вручную (программные токены ST-1, CE-1), автоматически при помощи считывателя (USB или PCMCIA версии считывателей), USB интерфейса (USB токен UB-1), или псевдослучайного алгоритма, в соответствии с которым генерируется challenge на CRYPTOServer (для RB-1 и KT-1 токенов). В ответ на ввод challenge токен выдает пароль (при условии введения корректного PIN кода) на сессию, который, (3) передается на систему контроля доступа защищаемого сервиса.

После получения сессионного пароля от абонента система контроля доступа защищаемого сервиса запрашивает вторично CRYPTOServer разрешение на предоставление доступа к услуге для данного абонента, передавая полученный на этапе (3) пароль. (4) CRYPTOServer сравнивает полученный пароль от системы контроля доступа защищаемого сервиса с результатом собственного преобразования challenge ключем абонента, и, в случае совпадения, выдает положительный ответ AUTH-ACCEPT (в терминах RADIUS) приложению (сервису) на доступ к услуге.

Для тех сервисов, которые не поддерживают двухступенчатой (two-factor) схемы аутентификации (например, классический SSH) существует возможность применения сокращенной процедуры аутентификации, при которой на этапе (1) система контроля доступа сервиса получает и логин учетной записи и сессионный пароль от пользователя не передавая абоненту challenge. Это возможно т.к. в программную логику каждого токена внесен алгоритм генерации псевдослучайного числа, который используется в CRYPTOServer. В результате, токен "знает" challenge, который будет сгенерирован для данной учетной записи CRYPTOServer'ом в следующий раз. Проблема которая может возникать при использовании сокращенной процедуры связана лишь с возможной рассинхронизацией токена и CRYPTOServer'а (токен сгенерировал по запросу пользователя пароль, а соответсвтующая процедура в CRYPTOServer не произошла), однако эта проблема решается при помощи синхронизации посредством www интерфейса CRYPTODeploy, или через контакт с группой техподдержки системы.

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