Статус: Участник
Группы: Участники
Зарегистрирован: 20.09.2012(UTC)
Сообщений: 19
|
afev написал:раз вы написали про CAdES-BES, то этот формат подписи подразумевает наличие подписанных атрибутов, с них и вычисляется хеш (в атрибуты входит и хеш данных) Мне всё равно, это подпись CAdES-BES, или какая-то другая. Мне просто надо плагином создать подпись, а проверить её соответствие подписанным данным с помощью JCP. Просто, этот плагин, как я понял, всё-таки по факту умеет создавать только подпись CAdES, т.е. усовершенствованную. Которая в свою очередь может быть двух типов: CADES-BES или CADES_X_LONG_TYPE_1, которая ещё сложнее. И когда я на демо-странице плагина выбираю простой вариант подписи, генерируется CADES-BES, а когда усовершенствованный -то CADES_X_LONG_TYPE_1. Но на деле и та и та - это усовершенствованные подписи, так что писать что плагин может использоваться для создания простой подписи - это как-то неправильно... Ну пускай будет усовершенствованная, это даже лучше, мне просто надо научиться её верифицировать на сервере. afev написал:Где будет происходить проверка подписи - на сервере? PrivateKey используется для подписи, createhashCMS - формирует подпись, а CMSVerify - проверяет. CMSVerify как раз и проверяет подпись и хеш: Код:
// I. Проверяем соответствие хеша данных в подписанных атрибутах хешу переданных (вложенных) данных.
...
if (!Array.toHexString(dm).equals(Array.toHexString(md)))
throw new Exception("message-digest attribute verify failed");
...
// II. Проверяем подпись.
signature.verify(sign);
...
Я это вижу. Но в этом примере подпись проверяется автономно, без всякого использования тех данных которые я подписал. Вы сами посмотрите этот ваш пример: Код:
public static void CMSVerify(byte[] buffer, Certificate[] certs, byte[] data)
throws Exception {
//clear buffers fo logs
out = new StringBuffer("");
out1 = new StringBuffer("");
final Asn1BerDecodeBuffer asnBuf = new Asn1BerDecodeBuffer(buffer);
final ContentInfo all = new ContentInfo();
all.decode(asnBuf);
if (!new OID(CMStools.STR_CMS_OID_SIGNED).eq(all.contentType.value))
throw new Exception("Not supported");
final SignedData cms = (SignedData) all.content;
final byte[] text;
if (cms.encapContentInfo.eContent != null)
text = cms.encapContentInfo.eContent.value;
else if (data != null) text = data;
else throw new Exception("No content for verify");
...
Этот byte[] text дальше используется в качестве хэша, с которым сверяется подпись. Т.е. если cms.encapContentInfo.eContent != null (а это так), то в качестве хэша берётся это самое "cms.encapContentInfo.eContent", а оно было извлечено из самой же подписи. И дальше подписанные данные никак не используются. Если же пример модифицировать, и написать "text = data;" то такая проверка не проходит. Точно так же не проходит, если написать "text = CMStools.digestm(data, "GOST3411");". Получается, что при верификации подписи мы никак её не сопоставляем с теми данными, на которых она была сгенерирована. Когда я впервые высказал эту мысль, ваш коллега Андрей * нашёл её абсурдной: Андрей * написал:
как без привязки... ? Зачем тогда ЭЦП, если я могу менять данные, а ЭЦП остается валидной!
И я с ним полностью согласен, я тоже этого не понимаю, однако ж, судя по примеру это так... Зачем тогда ЭЦП, если при её верификации внешние данные, которые ей соответствуют, никак не используются?!
|
