1. У etoken есть режим инициализации (через PKCS#11_Ext), при котором у токена нет пользователя SO, тем самым (на мой взгляд) повышается стойкость решения. Возможно ли что-либо подобное в продуктах компании Актив?
Вы имеете в виду возможность форматирования без прав SO? Поясните пожалуйста.
2. Некоторые разработчики СКЗИ для использования своих продуктов с rutoken (через PKCS#11) требуют покупки токенов через них, т.е. специально инициализированных. Не знаю, корректно ли это спрашивать у вас, но не раскроете тему, они прошивают что-то в CardOS? (Java?). Зачем интересуюсь - не слетит ли данная привязка при инициализации PKCS#11 или через APDU?
В CardOS они ничего не прошивают. Запись происходит, как правило, в неформатируемую область памяти. Поэтому привязка не должна слетать. Мы планировали так.
3. Насколько я понял, у rutoken ecp ключи хранятся не в DO, а в RSF. Где можно (если можно) об этом почитать?
Почитать можно в специальном документе, который предоставляется партнерам после заключения NDA. Запрос от организации можно прислать на адрес info@rutoken.ru
]]>1. У etoken есть режим инициализации (через PKCS#11_Ext), при котором у токена нет пользователя SO, тем самым (на мой взгляд) повышается стойкость решения. Возможно ли что-либо подобное в продуктах компании Актив?
2. Некоторые разработчики СКЗИ для использования своих продуктов с rutoken (через PKCS#11) требуют покупки токенов через них, т.е. специально инициализированных. Не знаю, корректно ли это спрашивать у вас, но не раскроете тему, они прошивают что-то в CardOS? (Java?). Зачем интересуюсь - не слетит ли данная привязка при инициализации PKCS#11 или через APDU?
3. Насколько я понял, у rutoken ecp ключи хранятся не в DO, а в RSF. Где можно (если можно) об этом почитать?