Цифровая подпись ответа web-http в Java (с использованием pgp) - PullRequest
1 голос
/ 23 декабря 2010

Я пытаюсь подписать http - веб ответ.По сути, я создаю ответ HTML и составной тип контента, подписываю ответ и затем добавляю цифровую подпись к ответу.Я думаю, что я близок, но в нескольких шагах, так как это не настоящая подпись PGP, поскольку добавленная подпись на самом деле HEXtoString.Главное - уметь правильно представлять подпись, чтобы ответ можно было правильно интерпретировать.Могли бы использовать некоторые предложения здесь, поскольку я довольно зеленый с этим.Заранее спасибо ... ниже приведены фрагменты кода, который я сейчас использую.

    StringBuffer myResponse = new StringBuffer("");
            myResponse.append(getHttpHeader());
            KeyPair pair2 = loadKeyPair();//loads a key pair from generated files

    if (signer==null)
        signer = Signature.getInstance("MD5withRSA");
    signer.initSign(pair2.getPrivate());
    signer.update(message.getBytes());
    byte[] b = signer.sign();
    FileOutputStream sigfos = new FileOutputStream(getFileLocation(0,localTest));
    sigfos.write(b);
    sigfos.close();
    //verify
    signer.initVerify(pair2.getPublic());//pubKey);
    signer.update(message.getBytes());
    if (signer.verify(b)){
        myResponse.append(message);
    }

    StringBuffer signed= new StringBuffer("");
    signed.append(boundary);
    signed.append(CRLF);
    signed.append("content-type: application/pgp-signature");
    signed.append(CRLF);
    signed.append("-----BEGIN PGP MESSAGE-----");
    signed.append(CRLF);
    signed.append("Version: 1");//update this
    signed.append(CRLF);
    signed.append(CRLF);

    signed.append(digSignature);//generated as HexString representation of signed file from above
    signed.append(CRLF);

    signed.append("-----END PGP MESSAGE-----");
    signed.append(CRLF);
    signed.append(boundary+"--");

            myResponse.append (signed);
            ServletOutputStream.println(myResponse);

Полученная "подпись", которая передается в байтахХеширование hexToString представления подписанных файлов.Я использую стандартные классы Java, но не уверен, что другие библиотеки дадут мне истинное представление PGP с символами вне представления 0-9a-f.идеи ??

Ответы [ 2 ]

0 голосов
/ 13 июля 2011

Эта проблема связана со стандартом NAESB-EDI. Если файл был отправлен в запросе http, и мы должны предоставить конкретный ответ. Мы используем SSL, и исходная информация должна быть зашифрована. Ответ представляет собой простой HTML (из 4 элементов) с дополнительной цифровой подписью ответа. Я решил создать ответ, заставить существующее программное обеспечение pgp создать подпись на основе сгенерированного ответа и затем добавить подпись к ответу. Таким образом, я больше не использую MD5 и не предоставляю ключи для публичного использования (кроме тех, которыми мы специально торгуем). Таким образом, ответ Джеймса частично верен и без SSL, он мало защищает от перехвата, так как ответ является открытым текстом. Тем не менее, без необходимой информации в запросе, они даже не получили бы правильный ответ. Вероятно, не получит ответ (не говоря уже о правильном).

0 голосов
/ 11 января 2011

Как код подтверждения загружается на клиент? Подробнее о заявке? Если это скрипт проверки, загруженный через HTTP, то схема в корне нарушена. Вам, вероятно, нужно использовать SSL, особенно если вы уже доказали это.

Не зная больше о вашей системе, похоже, что противнику в атаке «человек посередине» нужно только:

  1. Заменить открытый ключ в проверочном коде своим собственным.
  2. Отмените все «безопасные» коммуникации с собственной подписью.
  3. Ваш скрипт не видит ничего плохого, поскольку проверенный им открытый ключ был изменен противником.

Не говоря уже о том, что все сообщения в текстовом формате (так что, надеюсь, личная / конфиденциальная информация не передается?)

SSL решает эту проблему, потому что все сертификаты должны быть подписаны корневым центром сертификации, которому доверяет / установленный с помощью веб-браузера. Предполагается, что центры сертификации выдают сертификаты для доменов только тем людям, которые контролируют / владеют ими; следовательно, предыдущая атака не будет работать.

Теперь, если ваш клиент установлен в доверенном режиме таким образом, что злоумышленник не может вмешаться в него, вы можете продолжить использовать свою схему и при этом оставаться в безопасности. Например, если клиент установлен на клиентском ПК вручную или безопасно доставлен другим способом (например, через SSL и / или с использованием подписи кода).

(я заметил ссылку на хэширование MD5. Не используйте хэши MD5; MD5 поврежден.)

...