Есть несколько компонентов моего приложения, их связь должна быть безопасной в смысле Origin Verified. эти компоненты не могут иметь общий секрет. Поэтому я должен выбрать асимметричный ключ шифрования. при условии, что у меня два компонента A и B A отправляет некоторые данные F в B, а B должен проверить, что они действительно получены из A
A генерирует дайджест H из F со своим закрытым ключом
A присоединяет A_pub, H к своим параметрам запроса, отправляет F и объявляет отправителя / отправителя как A
B проверяет дайджест H с A_pub, предоставленным против F
очевидно, это выглядит хорошо, но если какой-то другой компонент V делает то же самое с V_pub и заявляет о себе как A, B все еще думает, что запрос пришел от A, так как этот H сделан с V_prv openssl проверяет в порядке.
Я хочу защитить от этой атаки V
Я использую ecparam secp112r1, чтобы минимизировать длину ключа. и клавиши неоднократно меняются.
- РЕДАКТИРОВАТЬ -
A, B и V - компоненты приложения, идентифицируемые уникальным URI. В настоящее время он предназначен для ограничения безопасного потока страниц. например Вы можете предположить, что A, B, V будут URL. То, что я хочу, это только A может быть обработано до B, и только B может перейти к C .... и я не хочу поддерживать глобальный / прикладной сеанс для этого. поэтому, если B может просто проверить происхождение этой ссылки на основе специальных параметров, A переданных ей в состоянии / без сеанса. и чем более универсальным он может быть, тем больше его можно будет использовать в других сценариях.
Однажды я решил сохранить контрольные суммы A_pub в надежном глобальном хранилище. однако, боюсь, не будет ли это чрезмерным проектированием?
другой способ приходит мне в голову - запросить исходный URL относительно открытого ключа. Однако я хочу избежать этого.