Token consumed что это в реестре

Извлечение ключа из токена с неизвлекаемым ключом

Довольно часто при оформлении сертификатов ключей электронной подписи можно наблюдать навязчивый пиар токенов с неизвлекаемым ключом. Продавцы из удостоверяющих центров уверяют, что, купив у них СКЗИ КриптоПРО CSP и токен с неизвлекаемым ключом (Рутокен ЭЦП или JaCarta ГОСТ), мы получим сертифицированные СКЗИ, обеспечивающие 100%-ную защиту от кражи ключей с токена. Но так ли это на самом деле? Для ответа на этот вопрос проведем простой эксперимент…

Конфигурация тестового стенда

1. ОС MS Windows 7 SP1
2. СКЗИ КриптоПРО CSP 3.9.8423
3. Драйверы Рутокен для Windows (x86 и x64). Версия: v.4.1.0.0 от 20.06.2016, WHQL-certified
4. Единый Клиент JaCarta и JaCarta SecurLogon. Версия 2.9.0 сборка 1531
5. КриптоАРМ Стандарт Плюс 5. Версия 5.2.0.8847.

1. Рутокен ЭЦП. Версия 19.02.14.00 (02)
2. JaCarta ГОСТ. Номер модели JC001-2.F09 v2.1

Методика тестирования

1. генерируется контейнер закрытого ключа и запрос на сертификат открытого ключа;
2. после прохождения в удостоверяющем центре процедуры сертификации из запроса получается сертификат;
3. сертификат в совокупности с контейнером закрытого ключа образует готовую для использования ключевую информацию. Данную ключевую информацию, записанную на носителе, будем называть исходным ключевым документом;
4. с исходного ключевого документа изготавливаются копии, которые записываются на отчуждаемые носители (далее будем называть их рабочими ключевыми документами) и передаются уполномоченным пользователям;
5. после изготовления необходимого количества рабочих ключевых документовисходный ключевой документ уничтожается или депонируется на хранение в орган криптографической защиты информации.

Проведение тестирования

1. Создадим исходный ключевой документ.
Описание

Для этого с помощью КриптоАРМ создадим в реестре контейнер закрытого ключа test-key-reestr, содержащий самоподписанный сертификат (CN=test)

2.Сформируем рабочие ключевые документы.
Описание

С помощью штатных средств СКЗИ КриптоПРО CSP (Пуск—>Панель управления—>КриптоПро CSP) скопируем ключевой контейнер test-key-reestr на ключевые носители Рутокен ЭЦП и JaCarta ГОСТ. Ключевым контейнерам на ключевых носителях присвоим имена test-key-rutoken и test-key-jacarta соответственно.
Описание приведено применительно к JaCarta ГОСТ (для Рутокен ЭЦП действия аналогичны):





Таким образом получили рабочие ключевые документы на JaCarta ГОСТ (контейнер test-key-jacarta) и Рутокен ЭЦП (контейнер test-key-rutoken).

3.Уничтожим исходный ключевой документ
Описание
Штатными средствами СКЗИ КриптоПРО CSP удалим из реестра ключевой контейнер test-key-reestr.

4. Скопируем ключевую информацию из рабочих ключевых документов
Описание

Попробуем скопировать ключевые контейнеры test-key-rutoken и test-key-jacarta обратно в реестр.
Описание приведено для JaCarta ГОСТ (для Рутокен ЭЦП действия аналогичны).

Как мы видим, ключевая информация успешно скопирована или, другим языком, извлечена из токенов с неизвлекаемым ключом. Получается, что производители токенов и СКЗИ врут? На самом деле нет, и ситуация сложнее, чем кажется на первый взгляд. Исследуем матчасть по токенам.

Матчасть

То, что на рынке принято называть токеном с неизвлекаемым ключом, правильно называется функциональным ключевым носителем (ФКН) (доп. инфо).

Главным отличием ФКН от обычных токенов (Рутокен S, JaCarta PKI, …) в том, что при выполнении криптографических преобразований (например, формирование электронной подписи) закрытый ключ не покидает устройство. В то время как при использовании обычных токенов закрытый ключ копируется с токена в память комптьютера.

Использование ФКН требует особой организации взаимодействия между прикладным криптографическим ПО и библиотекой СКЗИ (криптопровайдером или, по-другому, CSP).

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

По-новому взглянем на наш тестовый стенд

В качестве одного из ключевых носителей использовался Рутокен ЭЦП. Через «Панель управления Рутокен» о нем можно получить следующую информацию:

В последней строке указана фраза «Поддержка КриптоПРО ФКН: Нет», а это значит, что на токене нет апплета, с которым умеет работать СКЗИ КриптоПРО CSP. Таким образом, реализация технологии ФКН с использованием СКЗИ и токенов, описанных в конфигурации тестового стенда, невозможна.

Аналогичная ситуация и с JaCarta ГОСТ. Более того, СКЗИ КриптоПРО CSP, по крайней мере та версия, которая использовалась в тестовом стенде, использует данные ключевые носители как «обычные токены», которые, в свою очередь, являются просто носителями ключа.

Это утверждение очень просто подтвердить. Для этого надо поставить СКЗИ КриптоПРО CSP на чистую машину без драйверов от токенов и подключить токен JaCarta ГОСТ. ОС Windows 7 обнаружит токен JaCarta ГОСТ как «Устройство чтения смарт-карт Microsoft Usbccid (WUDF)». теперь можно попробовать создать ключ на токене и скопировать его в реестр компьютера. Весь функционал СКЗИ успешно отработает.

Как сделать, чтобы все было хорошо?

Чтобы с помощью продуктов ООО “КРИПТО-ПРО” реализовать технологию ФКН, необходимо:

1. Купить специальную версию библиотеки СКЗИ:
— для Рутокен ЭЦП — СКЗИ КриптоПРО Рутокен CSP.
— для JaCarta ГОСТ – СКЗИ КриптоПро ФКН CSP.

2. Одновременно с библиотекой СКЗИ необходимо приобрести специально подготовленные токены, содержащие в себе программные части (апплеты), с которыми умеет работать КриптоПРО Рутокен CSP или КриптоПро ФКН CSP соответственно.

Получается, что Рутокен ЭЦП и JaCarta ГОСТ не являются токенами с неизвлекаемым ключом?

Опять нет. Данные устройства могут реализовывать функционал ФКН (но, возможно, в меньшем объеме, чем при использовании их совместно с СКЗИ КриптоПРО), но для этого нужен софт, который умеет работать с апплетами размещенными на токенах. Таким софтом может быть КриптоАРМ Стандарт 5 Плюс. Он это умеет. При генерации ключевой пары в мастере КриптоАРМ можно выбрать криптопровайдер, который будет использоваться, например, Rutoken ECP или eToken GOST. Это и позволит использовать токен как ФКН.

Выводы

• Не верьте продавцам, чушь вам городящим. Использование обычных версий криптопровайдера КриптоПРО CSP и обычных Рутокен ЭЦП или JaCarta ГОСт не позволяют реализовать технологию ФКН.
• Для использования технологии ФКН совместно с продуктами ООО «КРИПТО-ПРО» необходимы как специально подготовленные токены, содержащие апплет, с которым умеет работать СКЗИ, так и специальные версии криптопровайдера КриптоПРО CSP, которые умеют работать с апплетом на токенах.
• Рутокен ЭЦП и JaCarta ГОСТ умеет самостоятельно реализовывать технологию ФКН, но для этого необходим специальный софт.

Руководство. Развертывание подключенного реестра во вложенной иерархии IoT Edge

В этом руководстве показано, как с помощью команд Azure CLI создать двухуровневую иерархию устройств Azure IoT Edge и развернуть подключенный реестр в качестве модуля на каждом уровне. В этом сценарии устройство на верхнем уровне обменивается данными с облачным реестром. Устройство на нижнем уровне обменивается данными с родительским подключенным реестром на верхнем уровне.

Общие сведения об использовании подключенного реестра с IoT Edge см. в статье Использование подключенного реестра с Azure IoT Edge.

Предварительные требования

• Используйте среду Bash в Azure Cloud Shell. Дополнительные сведения см. в статье Краткое руководство по Bash в Azure Cloud Shell.
• Если вы предпочитаете выполнять справочные команды CLI локально, установите Azure CLI. Если вы работаете в Windows или macOS, Azure CLI можно запустить в контейнере Docker. Дополнительные сведения см. в разделе Запуск Azure CLI в контейнере Docker.
  • Если вы используете локальную установку, выполните вход в Azure CLI с помощью команды az login. Чтобы выполнить аутентификацию, следуйте инструкциям в окне терминала. Сведения о других возможностях, доступных при входе, приведены в статье Вход с помощью Azure CLI.
  • Установите расширение Azure CLI при первом использовании, когда появится соответствующий запрос. Дополнительные сведения о расширениях см. в статье Использование расширений с Azure CLI.
  • Выполните команду az version, чтобы узнать установленную версию и зависимые библиотеки. Чтобы обновиться до последней версии, выполните команду az upgrade.

• Центр Интернета вещей Azure. Инструкции по развертыванию см. в статье Создание центра Интернета вещей с помощью портала Azure.
• Два ресурса подключенных реестров в Azure. Инструкции по развертыванию см. в кратком руководстве по созданию подключенного реестра с помощью Azure CLI или портала Azure.
  • Подключенный реестр для верхнего уровня может быть в режиме ReadWrite или ReadOnly. В этой статье предполагается, что используется режим ReadWrite, а имя подключенного реестра хранится в переменной среды $CONNECTED_REGISTRY_RW .
  • Подключенный реестр для нижнего уровня должен быть в режиме ReadOnly. В этой статье предполагается, что имя подключенного реестра хранится в переменной среды $CONNECTED_REGISTRY_RO .

Импорт образов в облачный реестр

Импортируйте следующие образы контейнеров в облачный реестр с помощью команды az acr import. Пропустите этот шаг, если вы уже импортировали эти образы.

Образ подключенного реестра

Чтобы обеспечить поддержку вложенных сценариев IoT Edge, образ контейнера для подключенной среды выполнения реестра должен быть доступным в частном реестре контейнеров Azure. С помощью команды az acr import импортируйте образ подключенного реестра в частный реестр.

# Use the REGISTRY_NAME variable in the following Azure CLI commands to identify the registry REGISTRY_NAME= az acr import \ --name $REGISTRY_NAME \ --source mcr.microsoft.com/acr/connected-registry:0.8.0 

Образы прокси-сервера API и IoT Edge

Для включения поддержки подключенного реестра во вложенных ресурсах IoT Edge необходимо развернуть модули для IoT Edge и прокси-сервера API. Импортируйте эти образы в свой частный реестр.

Модуль прокси-сервера API IoT Edge позволяет устройству IoT Edge предоставлять несколько служб с помощью протокола HTTPS на одном и том же порту, например 443.

az acr import \ --name $REGISTRY_NAME \ --source mcr.microsoft.com/azureiotedge-agent:1.2.4 az acr import \ --name $REGISTRY_NAME \ --source mcr.microsoft.com/azureiotedge-hub:1.2.4 az acr import \ --name $REGISTRY_NAME \ --source mcr.microsoft.com/azureiotedge-api-proxy:1.1.2 az acr import \ --name $REGISTRY_NAME \ --source mcr.microsoft.com/azureiotedge-diagnostics:1.2.4 

Образ hello-world

Для тестирования подключенного реестра импортируйте образ hello-world . Этот репозиторий синхронизируется с подключенным реестром и извлекается клиентами подключенного реестра.

az acr import \ --name $REGISTRY_NAME \ --source mcr.microsoft.com/hello-world:1.1.2 

Получение конфигурации подключенного реестра

Чтобы развернуть каждый подключенный реестр на устройстве IoT Edge в иерархии, необходимо получить параметры конфигурации из ресурса подключенного реестра в Azure. При необходимости выполните команду az acr connected-registry get-settings для каждого подключенного реестра, чтобы получить конфигурацию.

По умолчанию сведения о параметрах не содержат пароль токена синхронизации, который также требуется для развертывания подключенного реестра. При необходимости вы можете создать один из паролей, передав параметр —generate-password 1 или —generate-password 2 . Сохраните созданный пароль в надежном расположении. Вы не сможете получить его повторно.

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

# Use the REGISTRY_NAME variable in the following Azure CLI commands to identify the registry REGISTRY_NAME= # Run the command for each registry resource in the hierarchy az acr connected-registry get-settings \ --registry $REGISTRY_NAME \ --name $CONNECTED_REGISTRY_RW \ --parent-protocol https az acr connected-registry get-settings \ --registry $REGISTRY_NAME \ --name $CONNECTED_REGISTRY_RO \ --parent-protocol https 

Выходные данные команды включают строку подключения к реестру и связанные параметры. В следующем примере выходных данных показана строка подключения для подключенного реестра с именем myconnectedregistry с родительским реестром contosoregistry:

Настройка манифестов развертывания

Манифест развертывания — это документ JSON, в котором указано, какие модули следует развернуть на устройстве IoT Edge. Подробную информацию см. в статье Сведения о развертывании модулей и установлении маршрутов в IoT Edge.

Чтобы развернуть модуль подключенного реестра на каждом IoT Edge устройстве с помощью Azure CLI, сохраните следующие манифесты развертывания локально в виде файлов JSON. Используя сведения из предыдущих разделов, обновите соответствующие значения JSON в каждом манифесте. В следующем разделе вам потребуются пути к файлам для выполнения команды, применяющей конфигурацию к устройству.

Манифест развертывания для верхнего уровня

Для устройства верхнего уровня создайте файл манифеста развертывания deploymentTopLayer.json с приведенным ниже содержимым. Этот манифест похож на тот, который использовался в кратком руководстве по развертыванию подключенного реестра на устройстве IoT Edge.

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

Параметры модуля подключенного реестра

Важно! Если подключенный реестр прослушивает порт, отличный от 80 и 443, значение ACR_REGISTRY_LOGIN_SERVER (если оно указано) должно включать порт. Например, 192.168.0.100:8080 .

 "createOptions": "<\"HostConfig\":<\"Binds\":[\"/home/azureuser/connected-registry:/var/acr/data\"],\"PortBindings\":<\"8080/tcp\":[<\"HostPort\":\"8080\">]>>>" 

Параметры модуля прокси-сервера API

• Прокси-сервер API будет прослушивать порт 8000, настроенный как NGINX_DEFAULT_PORT . Дополнительные сведения о параметрах прокси-сервера API см. в репозитории GitHub для IoT Edge.

< "modulesContent": < "$edgeAgent": < "properties.desired": < "modules": < "connected-registry": < "settings": < "image": ".azurecr.io/acr/connected-registry:0.8.0", "createOptions": "<\"HostConfig\":<\"Binds\":[\"/home/azureuser/connected-registry:/var/acr/data\"]>>" >, "type": "docker", "env": < "ACR_REGISTRY_CONNECTION_STRING": < "value": "ConnectedRegistryName=;SyncTokenName=;SyncTokenPassword=REPLACE_WITH_SYNC_TOKEN_PASSWORD;ParentGatewayEndpoint=..data.azurecr.io;ParentEndpointProtocol=https" > >, "status": "running", "restartPolicy": "always", "version": "1.0" >, "IoTEdgeAPIProxy": < "settings": < "image": ".azurecr.io/azureiotedge-api-proxy:1.1.2", "createOptions": "]>>>" >, "type": "docker", "env": < "NGINX_DEFAULT_PORT": < "value": "8000" >, "CONNECTED_ACR_ROUTE_ADDRESS": < "value": "connected-registry:8080" >, "BLOB_UPLOAD_ROUTE_ADDRESS": < "value": "AzureBlobStorageonIoTEdge:11002" >>, "status": "running", "restartPolicy": "always", "version": "1.0" > >, "runtime": < "settings": < "minDockerVersion": "v1.25", "registryCredentials": < "cloudregistry": < "address": ".azurecr.io", "password": "", "username": "" > > >, "type": "docker" >, "schemaVersion": "1.1", "systemModules": < "edgeAgent": < "settings": < "image": ".azurecr.io/azureiotedge-agent:1.2.4", "createOptions": "" >, "type": "docker", "env": < "SendRuntimeQualityTelemetry": < "value": "false" >> >, "edgeHub": < "settings": < "image": ".azurecr.io/azureiotedge-hub:1.2.4", "createOptions": "],\"5671/tcp\":[],\"8883/tcp\":[]>>>" >, "type": "docker", "status": "running", "restartPolicy": "always" > > > >, "$edgeHub": < "properties.desired": < "routes": < "route": "FROM /messages/* INTO $upstream" >, "schemaVersion": "1.1", "storeAndForwardConfiguration": < "timeToLiveSecs": 7200 >> > > > 

Манифест развертывания для нижнего уровня

Для устройства нижнего уровня создайте файл манифеста развертывания deploymentLowerLayer.json со следующим содержимым.

В целом файл манифеста развертывания нижнего уровня такой же, как и файл манифеста развертывания верхнего уровня. Различия описаны ниже.

• В файле извлекаются образы из подключенного реестра верхнего уровня, а не из облачного реестра. Когда настраиваете подключенный реестр верхнего уровня сделайте так, чтобы он синхронизировал все необходимые образы локально, включая azureiotedge-agent , azureiotedge-hub , azureiotedge-api-proxy и acr/connected-registry . Устройство Интернета вещей нижнего уровня должно извлекать эти образы из подключенного реестра верхнего уровня.
• В файле используется настроенный токен синхронизации на нижнем уровне для проверки подлинности с подключенным реестром верхнего уровня.
• В файле настраивается конечная точка родительского шлюза с IP-адресом или полным доменным именем подключенного реестра верхнего уровня, а не с полным доменным именем облачного реестра.

В приведенном ниже манифесте развертывания $upstream используется в качестве IP-адреса или полного доменного имени устройства, на котором размещается родительский подключенный реестр. Но $upstream не поддерживается в переменной среды. Подключенному реестру необходимо считать переменную среды ACR_PARENT_GATEWAY_ENDPOINT , чтобы получить конечную точку родительского шлюза. Вместо $upstream подключенный реестр поддерживает динамическое разрешение IP-адреса или полного доменного имени из другой переменной среды.

На вложенном устройстве IoT Edge на нижнем уровне имеется переменная среды $IOTEDGE_PARENTHOSTNAME , равная IP-адресу или полному доменному имени родительского устройства. Вручную замените переменную среды, указав ее в качестве значения ParentGatewayEndpoint в строке подключения, чтобы избежать жесткого определения IP-адреса или полного доменного имени в коде. Так как родительское устройство в этом примере выполняет nginx на порте 8000, передайте $IOTEDGE_PARENTHOSTNAME:8000 . Также потребуется выбрать правильный протокол в ParentEndpointProtocol .

< "modulesContent": < "$edgeAgent": < "properties.desired": < "modules": < "connected-registry": < "settings": < "image": "$upstream:8000/acr/connected-registry:0.8.0", "createOptions": "<\"HostConfig\":<\"Binds\":[\"/home/azureuser/connected-registry:/var/acr/data\"]>>" >, "type": "docker", "env": < "ACR_REGISTRY_CONNECTION_STRING": < "value": "ConnectedRegistryName=;SyncTokenName=;SyncTokenPassword=;ParentGatewayEndpoint=$IOTEDGE_PARENTHOSTNAME:8000;ParentEndpointProtocol=https" > >, "status": "running", "restartPolicy": "always", "version": "1.0" >, "IoTEdgeApiProxy": < "settings": < "image": "$upstream:8000/azureiotedge-api-proxy:1.1.2", "createOptions": "]>>>" >, "type": "docker", "version": "1.0", "env": < "NGINX_DEFAULT_PORT": < "value": "8000" >, "CONNECTED_ACR_ROUTE_ADDRESS": < "value": "connected-registry:8080" >, "NGINX_CONFIG_ENV_VAR_LIST": < "value": "NGINX_DEFAULT_PORT,BLOB_UPLOAD_ROUTE_ADDRESS,CONNECTED_ACR_ROUTE_ADDRESS,IOTEDGE_PARENTHOSTNAME,DOCKER_REQUEST_ROUTE_ADDRESS" >, "BLOB_UPLOAD_ROUTE_ADDRESS": < "value": "AzureBlobStorageonIoTEdge:11002" >>, "status": "running", "restartPolicy": "always", "startupOrder": 3 > >, "runtime": < "settings": < "minDockerVersion": "v1.25", "registryCredentials": < "connectedregistry": < "address": "$upstream:8000", "password": "", "username": "" > > >, "type": "docker" >, "schemaVersion": "1.1", "systemModules": < "edgeAgent": < "settings": < "image": "$upstream:8000/azureiotedge-agent:1.2.4", "createOptions": "" >, "type": "docker", "env": < "SendRuntimeQualityTelemetry": < "value": "false" >> >, "edgeHub": < "settings": < "image": "$upstream:8000/azureiotedge-hub:1.2.4", "createOptions": "],\"5671/tcp\":[],\"8883/tcp\":[]>>>" >, "type": "docker", "status": "running", "restartPolicy": "always" > > > >, "$edgeHub": < "properties.desired": < "routes": < "route": "FROM /messages/* INTO $upstream" >, "schemaVersion": "1.1", "storeAndForwardConfiguration": < "timeToLiveSecs": 7200 >> > > > 

Настройка и развертывание модулей подключенного реестра

Следующие инструкции взяты из статьи Руководство. Создание иерархии устройств IoT Edge и предусмотрены для развертывания модулей подключенного реестра в иерархии IoT Edge. Подробное описание отдельных инструкций см. в том руководстве.

Создание устройств верхнего и нижнего уровней

Создайте виртуальные машины верхнего и нижнего уровней с помощью существующего шаблона ARM. Шаблон также устанавливает агент IoT Edge. Если вы хотите выполнить развертывание на собственных устройствах, см. статью Руководство. Установка и удаление Azure IoT Edge для Linux с инструкциями по настройке устройства вручную.

Чтобы обеспечить доступ к модулям, развернутым на устройстве IoT Edge, убедитесь, что на устройстве открыты такие порты для входящего трафика: 8000, 443, 5671, 8883. Инструкции по настройке см. в статье Как открыть порты для виртуальной машины с помощью портала Azure.

Создание и настройка иерархии

Создайте и настройте иерархию с помощью средства iotedge-config , выполнив следующие действия в Azure CLI или Azure Cloud Shell:

Скачайте средство настройки.

 mkdir nested_iot_edge_tutorial cd ~/nested_iot_edge_tutorial wget -O iotedge_config.tar "https://github.com/Azure-Samples/iotedge_config_cli/releases/download/latest/iotedge_config_cli.tar.gz" tar -xvf iotedge_config.tar 

config_version: "1.0" iothub: iothub_hostname: .azure-devices.net iothub_name: ## Authentication method used by IoT Edge devices: symmetric_key or x509_certificate authentication_method: symmetric_key ## Root certificate used to generate device CA certificates. Optional. If not provided a self-signed CA will be generated # certificates: # root_ca_cert_path: "" # root_ca_cert_key_path: "" ## IoT Edge configuration template to use configuration: template_config_path: "./templates/tutorial/device_config.toml" default_edge_agent: "$upstream:8000/azureiotedge-agent:1.2.4" ## Hierarchy of IoT Edge devices to create edgedevices: device_id: top-layer edge_agent: ".azurecr.io/azureiotedge-agent:1.2.4" ## Optional. If not provided, default_edge_agent will be used deployment: "./templates/tutorial/deploymentTopLayer.json" ## Optional. If provided, the given deployment file will be applied to the newly created device # hostname: "FQDN or IP" ## Optional. If provided, install.sh will not prompt user for this value nor the parent_hostname value container_auth: ## The token used to pull the image from cloud registry serveraddress: ".azurecr.io" username: "" password: "" child: - device_id: lower-layer deployment: "./templates/tutorial/deploymentLowerLayer.json" ## Optional. If provided, the given deployment file will be applied to the newly created device # hostname: "FQDN or IP" ## Optional. If provided, install.sh will not prompt user for this value nor the parent_hostname value container_auth: ## The token used to pull the image from parent connected registry serveraddress: "$upstream:8000" username: "" password: "" 

cd ~/nestedIotEdgeTutorial/iotedge_config_cli_release ./iotedge_config --config ~/nestedIotEdgeTutorial/iotedge_config_cli_release/templates/tutorial/iotedge_config.yaml --output ~/nestedIotEdgeTutorial/iotedge_config_cli_release/outputs -f 

Распакуйте пакет конфигурации. Перед этим следует установить средство распаковки.

sudo apt install zip unzip ~//.zip #unzip top-layer.zip 

sudo apt install zip unzip ~//.zip #unzip lower-layer.zip 

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

Развертывание модуля подключенного реестра вручную

Чтобы вручную развернуть подключенный модуль реестра на устройстве IoT Edge, используйте следующую команду:

az iot edge set-modules \ --device-id \ --hub-name \ --content

После успешного развертывания для подключенного реестра отобразится состояние Online .

Чтобы проверить состояние подключенного реестра, используйте команду az acr connected-registry show:

az acr connected-registry show \ --registry $REGISTRY_NAME \ --name $CONNECTED_REGISTRY_RO \ --output table 

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

После успешного развертывания для подключенного реестра отобразится состояние Online .

Чтобы устранить неполадки с развертыванием, выполните iotedge check на затронутом устройстве. Дополнительные сведения см. в руководстве по устранению неполадок.

Следующие шаги

Из этого краткого руководства вы узнали, как развернуть подключенный реестр на вложенном устройстве IoT Edge. Перейдите к следующему руководству, чтобы узнать, как извлечь образы из развернутого подключенного реестра.

Носитель ключа электронной подписи

Носитель ключа ЭП (токен) — это защищенная «флешка» для хранения электронной подписи. Выбор носителя зависит от сферы применения. Расскажем про виды токенов и их различия.

Что вы узнаете

• Почему нужен токен, а не флешка
• Какие есть виды токенов
• Что такое смарт-карта
• Что такое Bluetooth-токен

Почему обычная флешка не подойдет

Токен внешне напоминает флешку, но отличается от нее повышенным уровнем защиты: имеет пароль (пин-код) и сертификацию ФСТЭК/ФСБ. В продвинутых моделях есть аппаратное криптоядро устройства —встроенное средство криптографической защиты информации (СКЗИ). Если криптоядра нет, нужно установить специальную программу на ПК — криптопровайдер. Чаще всего используют СКЗИ «КриптоПро CSP». Программа покупается отдельно.

Виды токенов

Защищенные носители делятся на 2 вида: со встроенным СКЗИ и без него.

В таблице — сравниваем основные характеристики токенов.

Расскажем подробнее о каждом носителе.

Токены без СКЗИ (пассивные)

Такие носители подойдут для сдачи отчетности, участия в торгах, подписания документов по ЭДО или регистрации на Честном знаке. В них нет встроенного СКЗИ, они не подойдут для работы с алкоголем в ЕГАИС.

Рутокен Lite

Самый бюджетный вариант токена. В нем нет дополнительных функций, но есть все необходимое для работы. Сертифицирован ФСТЭК.

Токены с СКЗИ (активные)

Обладают более высоким уровнем безопасности, сертифицированы ФСТЭК и ФСБ. Формирование электронной подписи у них может производиться внутри носителя, а не в программе-криптопровайдере. При генерации аппаратных ключей может использоваться внутренняя криптография токена. Благодаря этому установка криптопровайдера на ПК при использовании данных моделей не нужна на таких ресурсах, как Госуслуги, сервисы ФНС, Честный знак и др.

Для работы в ЕГАИС необходимо приобретать именно такие токены.

Рутокен ЭЦП 3.0

Токен с улучшенными скоростными характеристиками и увеличенным объемом памяти — 128 Кб. Поддерживает новые алгоритмы шифрования и позволяет устанавливать расширенные политики пин-кодов. В линейке есть модели, которые работают и через USB, и по протоколу NFC. Подходит для работы в ЕГАИС.

Контейнер, токен для сертификатов и ключей openssh

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

Беда с токенами в том, что они заточены только под работу с x509 сертификатами и ключами rsa, да еще и с 1024 и иногда 2048.

А хотелось бы использовать ключи rsa 4k, ekdsa или ed25519 и сертификаты openssh, а не x509.

Видел кто нибудь токены, работающие с сертификатами openssh? Или софтовые реализации наподобие контейнеров криптопро?

Пока что ничего лучше файлика с контейнером luks не придумал. А хотелось бы, чтобы наподобие pks11 библиотека в ssh-add цепляла ключи и сертификаты openssh из своего контейнера или токена и вперед…

AVL ★
13.01.22 14:54:07 MSK

• Ответить на это сообщение
• Ссылка

Или софтовые реализации наподобие контейнеров криптопро?

«Софтовая реализация» это когда ты файл ключа с passphrase сгенерил. Ничего другого от софтовых реализаций в принципе не получишь, разница только в украшательствах.

firkax ★★★★★
( 13.01.22 15:32:15 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от firkax 13.01.22 15:32:15 MSK

Нет, софтовая реализация, это когда у тебя есть контейнер, в котором лежит ключ и сертификат openssh. Контейнер защищен парольной фразой. Сам контейнер может располагаться в файле или на токене (тот же файл, по сути, просто в токене).

Доступ ssh к сертификату и ключу осуществляет библиотека через ssh-agent.

По сравнению с ~/.ssh/* , во первых, нет нужды отдельно таскать с собой все эти файлы, достаточно иметь один файл-контейнер, да еще в токене, вместе с другими x509 сертификатами. Во вторых, нет нужды держать файлы ключа и сертификата на компьютере. Воткнул токен — есть контейнер. Вытащил — нет.

AVL ★
( 13.01.22 15:40:25 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от AVL 13.01.22 15:40:25 MSK

А, ну я это всё и обобщил как украшательства — удобства/неудобства доставки файла в нужное место, но почти никакой связи с безопасностью. Никакой защиты от кражи ключа через скомпрометированный комп.

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

firkax ★★★★★
( 13.01.22 15:48:59 MSK )
Последнее исправление: firkax 13.01.22 15:50:31 MSK (всего исправлений: 1)

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от firkax 13.01.22 15:48:59 MSK

В большинстве случаев компьютер во время работы никто и не компрометирует во время работы. Просто если ключи все время лежат в директории ~./ssh, рано или поздно их можно скопировать или забыть где-то вместе с компьютером.

Хотелось бы иметь токен — воткнул и есть, вытащил и нет. В том же криптопро есть контейнеры, в том числе и некопируемые с токена. И в этих контейнерах внутри полная свобода — гостовые ключи, например, о которых токен даже не догадывается. Так почему бы не сделать нечто подобное для сертификатов и ключей openssh?

AVL ★
( 13.01.22 16:40:40 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Юбикей банальный? Вроде всё умеет, что только можно хотеть.

Legioner ★★★★★
( 13.01.22 17:06:08 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 17:06:08 MSK

Ну, да. Полтосик денежных знаков страны двух падающих небоскрёбов и дело в шляпе. Немного непонятно: а почему нужен именно токен? Не, ну когда дело на устройстве налажено, то — это хорошо. Присунул и наши в дамках. Но тут же речь немножко о другом. Тут речь о том, что «комп. может быть утрачен». Результат — снова геморрой и мучительное напряжение очень дальних уголков памяти в лейтмотиве «когда-то я это делал, но разрази меня гром не помню как». Ключи-то есть, на утраченном девайсе «враг не пройдёт», но и самому проблем и занятий поднасыпало. Да ещё если для примастыривания этого эксклюзивного токена надо использовать не менее эксклюзивные подходцы. Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже? Уж тут-то и вспоминать ничего не надо даже при полной амнезии. В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

anonymous
( 13.01.22 17:19:43 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от AVL 13.01.22 16:40:40 MSK

В большинстве случаев компьютер во время работы никто и не компрометирует во время работы. Просто если ключи все время лежат в директории ~./ssh, рано или поздно их можно скопировать или забыть где-то вместе с компьютером.

Хорошо, это чуточку повышает защиту от разных неосторожностей, каждый сам решает насколько это ему существенно.

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

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

firkax ★★★★★
( 13.01.22 17:22:22 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от anonymous 13.01.22 17:19:43 MSK

Ну, да. Полтосик денежных знаков страны двух падающих небоскрёбов и дело в шляпе.

Ну токен дело такое, лучше взять качественное оборудование. Тем более, что не каждый день берёшь.

Кстати не полтосик, а два полтосика по-хорошему. А то и три. Запасные в сейфе на случай порчи/потери используемого.

Немного непонятно: а почему нужен именно токен?

Чтобы не пришлось спешно отзывать и менять все ключи, если появилось подозрение на то, что на твоём компе побывал троян. И вообще

Да ещё если для примастыривания этого эксклюзивного токена надо использовать не менее эксклюзивные подходцы.

Да вроде никаких подходцев не надо, всё стандартными средствами настраивается.

Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже? Уж тут-то и вспоминать ничего не надо даже при полной амнезии. В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

Главное отличие в том, что вирус, хозяйствующий на твоём компьютере, может вытащить любые твои файлы и любые пароли, которые ты нажимаешь на своей клавиатуре. А с криптотокена он ничего вытащить не может. В худшем случае он может подписать что-нибудь, пока крипто-токен вставлен и если крипто-токен не требует физичекого нажатия кнопки для каждой подписи. Но ключ твой в любом случае не утечёт и отзывать его не нужно будет.

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

Legioner ★★★★★
( 13.01.22 17:43:50 MSK )
Последнее исправление: Legioner 13.01.22 17:45:08 MSK (всего исправлений: 1)

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ну во первых нет сертификатов openssh, насчёт токенов всё что на openpgp умеет чисто в ключи rsa и пр и дружит с OpenSSH через gpg из коробки

sparks ★★★
( 13.01.22 17:47:54 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 17:06:08 MSK

Юбикей банальный? Вроде всё умеет, что только можно хотеть.

Ну во первых, не банальный, а полноценный. Есть такой, протестировал.

А во вторых, ничего он не умеет, кроме как хранить rsa ключи до 2048 бит.

Сертификаты openssh? нет known-host? нет

ключи ecdsa или ed25519? нет

AVL ★
( 13.01.22 19:27:02 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от anonymous 13.01.22 17:19:43 MSK

Немного непонятно: а почему нужен именно токен?

1. защита от копирования ключа (контейнера). Токен/флешку ведь тоже можно потерять. Мне очень нравится система трижды пин-код введен неверно — прощай контейнер.
2. нет нужды в монтировании/отмонтировании девайса. Вставил и пользуйся. Вытащил токен в любой момент и доступ пропал.

Тут речь о том, что «комп. может быть утрачен».

Да, но это рабочий комп(ы).

Ключи-то есть, на утраченном девайсе «враг не пройдёт», но и самому проблем и занятий поднасыпало.

никаких проблем. pki есть, просто выписал новый сертификат и записал в новый токен.

От забывчивости спасает скриптование операций. Я просто вызываю скрипт с логином и он сам мне все делает. Забыл, ну посмотри в скрипт.

Так и всё же, откройте тайну: чем тот же, упомянутый выше контейнер luks на обыкновенной флешке хуже?

1. Плохо защищает от копирования во время работы.
2. Требует рута.

Частично я это решил, создав банальный зашифрованный зип и скриптик, который его через archivemount монтирует, добавляет в ssh-agent и сразу отмонтирует. Теперь не нужно рута и в рабочем режиме ключи недоступны. Но раздражает кривизна archivemount (не работает с p7zip зашифрованными архивами, не отрабатывает неправильный пароль).

В гугел глянул как с тем luks-ом обращаться и за пяток минут вспомнил.

лукс хорош, но именно в этой задачи он не совсем удобен.

AVL ★
( 13.01.22 19:38:19 MSK ) автор топика

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от firkax 13.01.22 17:22:22 MSK

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

Криптопро работает со своим контейнером. Ему что токен, что реестр, что файл.

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

Попробуй. Создай контейнер криптопро с битом некопируемости и скопируй. Мне вот в налоговой ЭЦП так сделали, было бы круто скопировать в файл, у меня не вышло и в интернетах что-то молчок.

AVL ★
( 13.01.22 19:42:22 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 17:43:50 MSK

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

AVL ★
( 13.01.22 19:44:04 MSK ) автор топика

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от AVL 13.01.22 19:27:02 MSK

Тебе надо использовать OpenPGP интерфейс.

Legioner ★★★★★
( 13.01.22 19:47:28 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от sparks 13.01.22 17:47:54 MSK

Ну во первых нет сертификатов openssh

man sshd_config HostCertificate Specifies a file containing a public host certificate. The cer‐ tificate's public key must match a private host key already spec‐ ified by HostKey. The default behaviour of sshd(8) is not to load any certificates. man ssh-keygen CERTIFICATES ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and a set of options that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8). ssh-keygen supports two types of certificates: user and host. User certificates authenticate users to servers, whereas host certificates authenticate server hosts to users. To generate a user certificate: 

AVL ★
( 13.01.22 19:48:16 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 19:47:28 MSK

Тебе надо использовать OpenPGP интерфейс.

AVL ★
( 13.01.22 19:49:06 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от AVL 13.01.22 19:49:06 MSK
Legioner ★★★★★
( 13.01.22 19:50:31 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 19:50:31 MSK

Там только rsa ключи. Да, до 4k, но, например, в федоре вообще их отключили из хостов.

А еще есть сертификаты openssh иони там свои, не X509. Их использование позволяет настроить доступ целиком в системе, без троганий ~/.ssh плю можно вдавать урезанные по правам сертификаты.

ed25519 таки есть. Я просто настраивал PIV и там их нет.

ed25519 (sign / auth only)

AVL ★
( 13.01.22 20:07:26 MSK ) автор топика
Последнее исправление: AVL 13.01.22 20:09:34 MSK (всего исправлений: 2)

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от AVL 13.01.22 19:42:22 MSK

У меня совершенно нет желания ставить себе всё это и реверсить как оно работает. Но комп это не магическое устройство, поэтому апеллции к чудесным программам я отклоняю. Если контейнер представлен чем-то, записанным на обычный компьютерный диск или флешку — то воспрепятствовать его копированию программой, запущеной на том же компе и имеющей доступ к этому носителю информации — принципиально невозможно. Максимум, что они могли сделать — это запутать способ хранения контейнера (security through obscurity), но это не настоящее препятствие, а только преграда от ленивых, которым будет влом изучать как оно там устроено.

Мне вот в налоговой ЭЦП так сделали,

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

firkax ★★★★★
( 13.01.22 20:38:10 MSK )
Последнее исправление: firkax 13.01.22 20:40:44 MSK (всего исправлений: 2)

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от firkax 13.01.22 20:38:10 MSK

Если контейнер представлен чем-то, записанным на обычный компьютерный диск или флешку

контейнер записан в токен с установленным битом неизвлекаемости.

Возможно тебе таки выдали аппаратный токен

я его сам принес, рутокен ecp. но внутри токена теперь контейнер криптопро.

AVL ★
( 13.01.22 20:47:28 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от AVL 13.01.22 20:47:28 MSK

контейнер записан в токен с установленным битом неизвлекаемости

Это называется запретом на экспорт. КриптоПРО позволяет перемещать сертификаты или запрещает их перемещать. Но только средствами самой КриптоПРО — запрет на экспорт распространяется только на программное обеспечение от КриптоПРО. Это совершенно не значит, что экспорт содержимого не может быть осуществлён. Сродни связки ключей. Они есть, но при переносе на другое устройство в исходном состоянии они по идее будут непригодными. В этом случае, когда «хозяйский софтец» не может помочь, сертификаты извлекаются в рабочем процессе. Об этом вам и рассказывают. Словосочетание «бит неизвлекаемости» — это «быстрый уровень вхождения в проблему», как бубунта после виндовсы.

anonymous
( 13.01.22 22:07:16 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 17:43:50 MSK

Ну и ещё отличие так сказать управленческое. Если ты это делаешь не для себя, а для сотрудников. В юбикее ты можешь быть уверен. А в том, что сотрудник будет грамотно пользоваться всеми этими люксами, а не поставит туда пароль 123 и вообще не скопирует ключ для удобства куда-нибудь поближе, уверенным быть сложней.

Не очень-то понятно со стороны реализатора этого всего мероприятия. Со стороны не управленца, а того, кто всё это будет делать. Вот у вас получается, что конечный пользователь и сам себе контейнеры создаёт, и пароли на них назначает. А ключики для ssh этот пользователь тоже сам себе генерирует? Или вот возьмём, например, токен. И возьмём какой-нибудь дистрибутив. Debian-а или его производных, или там что-то из RedHat и тоже его производных. Установим на подходящее железо и радостно всунем этот токен в подходящий порт. И вот с этого токена вдруг и неожиданно сертификаты взяли и обслужили некую попытку соединения. Вы какой дистрибутив порекомендуете взять, чтоб его без всякого допиляжа и присовывания всевозможных дров можно было бы использовать для всевозможных токенов? Ну, например, для rutoken lite дров добавлять не надо. Ан, всё равно при присовывании этого токена сертификаты всё равно придётся чем-то читать и как-то и кому-то всё это дело настраивать. Пользователю? Ну, если пользователь сам себе luks-овые контейнеры мастырит, то ему и с токенов инфу почитать — это как два пальца об асфальт. вы не могли бы объяснить от кого вы собственно секретутности усиливаете? Я этого момента не понял.

anonymous
( 13.01.22 22:24:39 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от anonymous 13.01.22 22:24:39 MSK

Не знаю, что там с rutoken lite, но вообще для токенов есть стандартные интерфейсы и протоколы и ничего там пилить не надо, обычный ssh и gpg поддерживают. Российские криптотокены вероятно нужны для русской посконной гостовской криптографии, с ней, конечно, будут проблемы, но то такое.

Legioner ★★★★★
( 13.01.22 23:00:54 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Legioner 13.01.22 23:00:54 MSK

для токенов есть стандартные интерфейсы и протоколы и ничего там пилить не надо

А вы не могли бы в конкретных числах озвучить количество этих самых «стандартных» интерфейсов для токенов?

anonymous
( 14.01.22 01:09:06 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от anonymous 14.01.22 01:09:06 MSK

Я не Legioner, но подскажу.

Есть библиотека с интерфейсом pkcs11 , которую используют ssh, gpg, браузеры и т.д. В рутокен лайт она тоже есть, но рутокен лайт не поддерживает rsa, а только госты, так что в большинстве случаев мимо. Рутокен эцп держит и Rsa и гост, что выглядит предпочтительней.

И еще есть java интерфейс. Он обычно используется в банках, но они в последнее время тоже перешли на криптопро.

AVL ★
( 14.01.22 11:39:18 MSK ) автор топика

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от anonymous 13.01.22 22:24:39 MSK

Не очень-то понятно со стороны реализатора этого всего мероприятия. Со стороны не управленца, а того, кто всё это будет делать.

Да как обычно реализуется pki. Есть сотрудник, который выписывает сертификаты и ключи. Иногда ключ на токене создает пользователь. В случае с ssh это плохая идея. В ssh весь процесс создания ключа и сертификата должен по идее проходить в отделе безопасности. Пользователю просто выдают токен.

Вот у вас получается, что конечный пользователь и сам себе контейнеры создаёт, и пароли на них назначает.

Не создает, а копирует, если может. Мне вот в тендерной площадке создали контейнер криптопро на токене, а я взял и скопировал его в реестр и вертел ваш токен…

А ключики для ssh этот пользователь тоже сам себе генерирует?

Нет. Пользователь получает или приносит токен, на котором генерируется ключ и сертификат.

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

А пинкод на токен они тоже сами ввели?

Вы какой дистрибутив порекомендуете взять, чтоб его без всякого допиляжа и присовывания всевозможных дров можно было бы использовать для всевозможных токенов? Ну, например, для rutoken lite дров добавлять не надо. Ан, всё равно при присовывании этого токена сертификаты всё равно придётся чем-то читать и как-то и кому-то всё это дело настраивать. Пользователю? Настраивает служба техподдержки, как обычно. Драйверы на большинство токенов уже есть в дистре. Библиотека pks11 на рутокен или другие токены, это просто один файл, который бросают в /usr/lib64

Все остальное есть в дистрибутиве.

Ну, если пользователь сам себе luks-овые контейнеры мастырит, то ему и с токенов инфу почитать — это как два пальца об асфальт. вы не могли бы объяснить от кого вы собственно секретутности усиливаете? Я этого момента не понял.

Секурность заключается в том, что нет средств извлечь/скопировать ключ с токена. Поэтому если я пришел и ушел с токеном, то значит и ключ со мной ушел. Уволился, сдал токен — ну значит и подпись отдал.

А с луксом это просто файлы, которые во время работы никак не защищены.

AVL ★
( 14.01.22 11:50:28 MSK ) автор топика

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от anonymous 13.01.22 22:07:16 MSK

Это называется запретом на экспорт. КриптоПРО позволяет перемещать сертификаты или запрещает их перемещать. Но только средствами самой КриптоПРО — запрет на экспорт распространяется только на программное обеспечение от КриптоПРО. Это совершенно не значит, что экспорт содержимого не может быть осуществлён. Сродни связки ключей. Они есть, но при переносе на другое устройство в исходном состоянии они по идее будут непригодными. В этом случае, когда «хозяйский софтец» не может помочь, сертификаты извлекаются в рабочем процессе. Об этом вам и рассказывают. Словосочетание «бит неизвлекаемости» — это «быстрый уровень вхождения в проблему», как бубунта после виндовсы.

Это все замечательно, но это лучше, чем ничего. В принципе и токен, это тоже по сути эфемерный «бит неизвлекаемости». Кто мешает попилить чип и прочитать его послойно? А можно взломать прошивку. Хрен знает, сколько там дыр. Да и сами алгоритмы взламывают со временем. Но в настоящий момент нет (широко)известных способов скопировать контейнер криптопро, как нет (широко)известных способов вытащить ключи из токена. Поэтому, это лучше, чем лукс-контейнер, который можно скопировать командой dd. Вот что я хотел сказать.

AVL ★
( 14.01.22 11:55:32 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от AVL 13.01.22 19:48:16 MSK

действительно, прикольно, я всегда в контексте certificate подставлял x509. openpgp работает через gpg, там нет x509 оно эмулируется через opensc

sparks ★★★
( 14.01.22 15:48:31 MSK )

• Ответить на это сообщение
• Ссылка