입니다. 내 응용 프로그램의 여러 구성 요소가 있으므로 Origin Authentified라는 의미에서 보안 통신이 필요합니다. 이러한 구성 요소는 공통 비밀을 공유 할 수 없습니다. 따라서 비대칭 키 암호화를 선택해야합니다. 내가 한 가정 두 가지 구성 요소 A 및 B A가 B-F 및 B이 가지고 어떤 데이터가 정말 Aopenssl 피싱 : V 클레임은
A에서 온 것을 확인하기 위해 보내는 개인 키
A가 A_pub, H을 첨부 그와 F의 H을 소화 생성의 요청 파라미터, F를 보내고 A
B는이대해 제공된 A_pub으로 H 다이제스트 검증으로 송/발신자 선언 10
분명히 그것은 좋아 보이지만 다른 구성 요소 V가 V_pub와 같은 수행하고 A로 자신을 주장하는 경우, B 여전히 V_prv하려면 openssl이 좋아 검증과이 H이 이루어으로 요청이 A에서 나온 생각한다.
는 내가 키 길이를 최소화하기 위해 ecparamsecp112r1을 사용하고 V
의 공격으로부터 보호를 제공합니다. 키는 반복적으로 변경됩니다.
- 편집 -
A, B 및 V 고유 URI에 의해 식별 된 응용 프로그램 구성 요소입니다. 현재는 보안 페이지 흐름을 제한하려고합니다. 예 : 당신은 가정 할 수 있습니다 A, B, V 내가 원하는 건 A은 B으로 처리 할 수 있으며 B 만 진행할 수 있습니다. C .... 그리고 저는이를 위해 전체/응용 프로그램 세션을 유지하고 싶지 않습니다. 그래서 만약 B이 특별한 매개 변수 A에 기반하여이 링크의 원점을 확인할 수 있다면 상태/세션리스 방식으로 전달됩니다. 좀 더 일반적인 것은 다른 시나리오에서도 구현할 수있는 재사용 성이 높을 수 있다는 것입니다.
신뢰할 수있는 전역 저장소에서 체크섬을 A_pub으로 유지한다고 생각한 적이 있습니다. 그러나 나는 그것이 과도한 공학이되지 않을까 두렵다.
내 마음에 오는 또 다른 방법은 공개 키와 관련된 원본 URL을 쿼리하는 것입니다. 그러나 나는 그것을 피하고 싶다.
두 가지 가능성이 있습니다 : 1)'A'와'V'는 단지 '제 1 자'와 '제 2 자'와 같은 임의의 식별자이고'B'가 그것들을 지키는 한은 중요하지 않습니다 직진. 2)'A'와'V'는 임의적이지 않고 특정한 것을 나타냅니다. 어떤 경우인지 알려주지 않으면 유용한 답변을 얻을 수 없습니다. –
내 편집 –