Exception Management of Well-behaved Users in Group Signature Schemes based on Linear Encryption

선형 암호문을 이용하는 그룹 서명 기법에서 정상적인 사용자를 위한 예외 처리

Abstract

Open and Judge in group signature schemes can be brought into the management of misbehaving users. Unfortunately, when Open and Judge of a certain group signature are used into another group signature that adopts the same linear encryption, they are not suitable for processing exceptions due to well-behaved users. In this paper, for all group signatures based on the linear encryption, we propose and discuss new Open and Judge that are suitable for processing exceptions due to well-behaved users.

그룹 서명 기법에서의 Open과 Judge는 잘못된 행동을 하는 사용자를 처리하기 위해 동원될 수 있는 방법 중에 하나이다. 불행하게도 어떠한 그룹 서명의 Open과 Judge는 같은 선형 암호문을 사용하는 다른 그룹 서명에서 사용될 때, 정상적인 사용자의 뜻하지 않은 오류를 처리하는 데에는 적합하지 않을 수도 있다. 이 논문에서는 선형 암호문을 이용하는 모든 그룹 서명 기법을 위해서 정상적인 사용자의 뜻하지 않은 오류 처리를 위한 Open과 Judge에 대해서 알아보고, 이를 대체하기 위한 기법들을 제안한다.

I. 서론

서비스 제공의 증거로 디지털 서명을 받는 것은 자연스러운 일이다. 국내 은행들과 지불 대행업체들은 이미 자금 이체와 지불 등의 증거로써 사용자들에게 디지털 서명을 요구하고 있다. 이러한 디지털 서명에는 사용자의 실명에 대한 정보가 들어 있고, 이를 근거로 사용자들에게 서비스 제공의 대가를 요구하고 있다. 그러나 이러한 지불 시스템은 사용자의 개인 정보에 대한 별다른 인식 없이 이루어지고 있다. 이는 앞으로 익명성을 가진 서명 기법이 자금 이체와 지불 등의 증거로써 사용될 수 있는 이유이기도 하다.

그룹 서명 기법은 서명자의 익명성을 제공하는 서명 기법 중에 하나로, D. Chaum의 기본 개념의 제안^[1] 이후로 꾸준히 연구가 이루어졌다. 특히 최근에는 그룹 서명의 응용에 관한 연구가 이루어지고 있다. 그룹 서명 기법은 특히나 사용자의 익명성에만 신경쓴 것이 아니라 익명성을 악용하는 경우에 대한 고려도 포함하고 있어, 시스템에서 그룹 서명 기법을 어떻게 구성하고 사용하느냐에 따라 개인 정보 보호와 공익을 균형 있게 관리할 수 있다. 그러나 그룹 서명 기법은 오로지 잘못된 행동을 반복하는 사용자에 대한 고려만 주로 되어 있어, 정직한 사용자의 의도하지 않은 오류에 대해서 지나치게 민감하게 반응하여, 사용자의 익명성을 취소하려고 할지도 모른다. 이는 경우에 따라서 지나치게 가혹한 처분일 수 있다.

이 논문에서는 다음과 같은 내용을 포함하고 있다.

• 그룹 서명 기법에서 정상적인 사용자들에게서 발생할 수 있는 문제에 대한 예외 처리의 필요성의 고찰

• MMO06^[2]에서 사용되는 Open/Judge가 이러한 예외 처리에 사용될 수 없는 이유의 고찰

• 이를 동일한 선형 암호문을 사용하는 BBS04^[3]와 같이 잘 알려진 기존의 그룹 서명 기법에 적용하였을 때 발생할 수 있는 문제

• 이를 대체하기 위한 OpenHU과 JudgeHU에 대해서 제안하고, 이 제안이 기존의 MMO06의 Open/Judge에서와 같은 문제가 발생하지 않음을 랜덤 오라클을 이용하여 증명

• 응용 환경에 효율적으로 동작할 수 있는 Open/BatchProof/BatchJudge의 제안

이 논문의 나머지 구성은 다음과 같다. II장은 이 논문을 이해하기 위한 기초적인 내용을 다루고, III장에서는 선형 암호문을 사용하는 그룹 서명 기법에서 의도치 않은 오류를 위한 Open/Judge에 대해서 MMO06을 예를 들어 알아본다. IV장에서는 사용자 식별자만을 노출하는 새로운 Open과 Judge에 대해서 제안하고, 그 안전성에 대해서 살펴본다. V장은 이 논문의 결론을 담는다.

II. 일러두기

2.1 겹선형 접합

겹선형 접합(bilinear pairing) e : #는 두 순환군(cyclic group) #과 # 위의 각각 한 원소로부터 한 순환군 #의 한 원소를 구하는 맵(map)으로 다음과 같은 성질을 갖는다.

• bilinearity: 모든 #, #와 #에 대해서, #이다.

• non-degeneracy: 만약 #, #이고, 모든 #, #에 대해서 #, #이다. (여기서 #는 #의 항등원)

• computable: 모든 #, #에 대해서, e(g₁,g₂)는 쉽게 계산될 수 있다.

2.2 그룹 서명 기법과 선형 암호화 (Linear Encryption)

D. Chaum이 제안한 그룹 서명(group signature) 기법은 서명자의 익명성을 보장하는 서명 기법 중에 하나이다^[1]. 그룹 서명에는 그룹과 사용자에게 멤버십 인증서를 발급하고 관리하는 멤버십 관리자(issuer)와 익명취소 관리자(opener)가 존재하며 때로는 이 둘을 그룹 매니저(group manager, GM)로 가정하기도 한다^[4,5]. 그룹 서명 기법에서 다음과 같은 구성을 갖는다.

• GKeyGen: 그룹 공개키, 멤버십 인증서 발행키, 익명 철폐키를 생성한다.

• Join/Iss: 멤버십 관리자는 특정한 그룹 구성원의 멤버십 인증서(또는 그룹 서명키)를 생성한다. Join은 사용자가 Iss는 멤버십 관리자가 실행한다. 이 둘은 서로 통신 프로토콜로써 연결되어 동작한다.

• GSign: 사용자는 멤버십 인증서(또는 그룹 서명키)를 이용하여 메시지의 그룹 서명을 생성한다.

• GVerify: 그룹 서명의 유효성을 확인한다.

• Open: 익명취소 관리자는 익명 철폐키를 이용하여 서명으로부터 사용자의 식별자와 그 계산 과정이 올바르다는 증거를 구한다.

• Judge: Open 결과의 유효성을 확인한다.

[2,3]과 같은 그룹 서명 기법은 서명을 생성할 때, 사용자의 식별자를 암호화하기 위하여 선형 암호화(linear encryption) 기법을 이용한다. 선형 암호화 기법은 DDH(Decisional Diffie-Hellman) 문제가 안전하지 않은 그룹에서 IND-CPA 안전하도록 설계된 암호화 기법으로, 오더(order)가 소수 p인 그룹 #에 대해서 다음과 같이 동작한다.

• (pk,sk)←KeyGen(): #, 

#, u^ξ₁ = v^ξ₂ =h, pk←(u,v,h), sk←(ξ₁ ,ξ₂)

• C←Enc(pk,M): #, C←(C₁ = u^α, C₂= v^β ,C₃ = Mh^{α + β})

• M←Dec(pk,sk,C): M←C_3,(#)

2.3 그룹 서명을 위한 보안 정의

그룹 서명은 공식적인 성질이 정립되기 전까지 다양한 그룹 서명에서 정의되어 사용된 비공식적인 보안 정의들과 BMW04 모델^[4]이나 BSZ05 모델^[5]에서 정립된 공식적인 보안 정의들을 가지고 있다. 이 논문의 원활한 이해를 위해서는 다음과 같은 비공식적인 정의 또는 공식적인 정의에 대해서 알아볼 필요가 있다.

• 익명성(anonymity)과 비연결성(unlinkability): 전통적으로 익명성은 GM을 제외한 누군가에게 그룹 서명이 주어졌을 때, 이 그룹 서명이 누가 생성했는지 알 수 없는 것을 의미한다. 비연결성은 GM을 제외한 누군가에게 두 그룹 서명을 주었을 때, 이 둘이 같은 사용자가 생성한 것인지 아닌지 알 수 없다는 것이다. 이 둘 모두는 BMW04 모델^[4]의 ‘완전 익명성(full-anonymity)’과 BSZ05 모델^[5]의 ‘익명성’에 포함된다. 완전 익명성의 경우 GM을 제외한 사용자의 그룹 서명키까지 주어진 환경에서의 익명성을 의미하며, BSZ05 모델의 익명성은 익명 철폐키를 제외한 멤버십 인증서 발급키 등을 포함한 나머지 모든 정보가 주어졌을 때의 익명성을 의미한다. MMO06^[2]의 CPA-익명성(CPA-anonymity)은, BBS04^[3]의 CPA-완전 익명성(CPA-full-anonymity)이 BMW04 모델^[4]의 완전 익명성에서 그룹 서명키를 공격자에게 주지 않은 경우를 의미하듯, BSZ05 모델^[5]의 익명성에서 Join/Iss, Open 등에 관련된 오라클들이 주어지지 않은 경우에 대한 것이다.

• 지역 연결성(local linkability)과 전역 연결성(global linkability): 강전일 등과 황정연 등이 그들의 논문^[6,7]에서 이 두 개념을 사용하였으며, ‘지역 연결성’이란 ‘특정한 비밀키(연결키)를 갖는 지역적으로 제한된 어떠한 관리자(서비스 제공자)가 자신에게 주어진 그룹 서명들을 동일한 사용자가 서명한 그룹 서명들끼리 분류할 수 있는 성질’로 요약할 수 있다. 이 들은 익명 취소 관리자가 갖는 연결성을 전역 연결성이라고 하였다.

• 무죄입증성(exculpability)과 강한 무죄입증성(strong-exculabililty): 무죄입증성이란 ‘서명자 이외에 Open의 결과가 그 사용자인 그룹 서명을 생성할 수 없다’는 것으로 GM이 제외된 경우에 한한다. 이에 반해서 강한 무죄입증성은 ‘GM을 포함한’ 무죄입증성이라고 볼 수 있다. BMW04 모델^[4]의 ‘완전 추적 가능성(full-traceability)’과 BSZ05 모델^[5]의 ‘추적 가능성(traceability)’은 강한 무죄입증성을 포함하고 있다. 일반적으로 GM이 알 수 없고 사용자만 알고 있는 어떤 비밀키가 그룹 서명의 생성에 사용되면 강한 무죄입증성을 가질 수 있어, 이 논문에서는 이 차이를 설명하기 위하여 사용한다.

• 비편제성(non-frameability): 여러 형태로 BSZ05 모델^[5]에 다시 정의된 보안 성질로, 사용자가 정말로 생성한 그룹 서명이 아니라면 Judge를 통과할 수 있는 Open 결과(즉, 증명)를 생성할 수 없다는 것이다. 이 모델은 공격자에게 멤버십 인증서 발급키와 익명 철폐키를 주며, 공격자가 서명 오라클(signing oracle)에 질의하지 않은 메시지와 그룹 서명에 대해서 Open의 결과를 요구한다.

III. 선형 암호문을 사용하는 그룹 서명 기법에서 의도치 않은 오류의 처리

3.1 응용 환경: 서비스 제공의 증거로의 그룹 서명

서비스 제공자는 익명 사용자에게 서비스를 제공해주고, 서비스 제공자는 익명 사용자로부터 그룹 서명을 받는다. 서비스 제공자는 이러한 서비스 제공의 대가로 익명 사용자로부터 금전적 보상을 받아야만 한다. 그러나 서비스 제공자가 사용자의 실명과 관련하여 어떠한 정보도 없을 때, 서비스 제공의 대가를 사용자에게 직접 요구하는 것은 쉽지 않다. 당연하게도, 서비스 제공의 대가와 관련된 요구는 GM을 통할 수 밖에 없다. 서비스 제공자는 GM에게 그룹 서명을 전달하고, 서비스 제공의 대가를 사용자에게 요구해줄 것으로 요청해야 한다. GM은 서비스 제공자에게 받은 그룹 서명을 열어보고 사용자의 식별자를 알아낸 뒤, 이를 근거로 사용자에게 서비스 제공의 대가를 요구할 수 있다. 이 때, 사용자는 자신이 생성했던 그룹 서명도 저장해놓지 않는 이상 자신이 생성했는지 확인할 수 없으므로, GM은 사용자의 식별자가 정당한 절차를 거쳐 얻었음을 보이기 위한 증명을 첨부해야 한다. 증명이 올바른 경우, 사용자는 서비스 대가를 GM을 통해 서비스 제공자에게 지불한다.

서비스 제공자는 당연히 자신이 사용자에게 받았던 그룹 서명을 근거로 자신이 받게 되는 요금을 예상할 수 있을 것이다. 하지만 서비스 제공자가 실제로 GM으로부터 받을 수 있는 요금은 그와 다를 수 있다. 사용자가 뜻하지 않은 오류로 인하여 그룹 서명을 중복하여 생성한다거나, 잘못된 메시지에 그룹 서명을 생성하여 전달하는 경우, 사용자는 자신이 서명하였다 하더라도, 자신에게 청구되는 요금에 대해서 동의하지 못할 수도 있다. 예를 들어, 현재에도 인터넷에 있어서 흔히 있는 프로그램 오류나 사용자의 이용 미숙에 따른 이중 결제 등이 여기에 속한다. 이 때, GM은 서명된 메시지와 서명자를 확인하여 사용자의 항의를 어느 정도 검증할 수 있다. 따라서 GM은 서비스 제공자에게 서비스 제공자가 실제로 얻게 되는 요금이 다르다는 사실을 설득해야 할 필요가 있다.

그룹 서명 기법은 위와 같은 경우에 대해서 그룹 서명의 익명성을 취소하는 방법으로 Open과 Judge를 제공하고 하고 있다. GM은 Open과 Judge 과정을 통하여 그룹 서명으로부터 사용자의 식별자가 올바르게 복호화 되었음을 증명할 수 있다. 그러나 일반적으로 Open 과정은 잘못된 행위의 사용자를 대상으로 하기 때문에 위와 같은 경우의 사용에 적합하지 않을 수 있다. 만약, Open의 결과 사용자의 멤버십 인증서 전부가 노출되거나, 일부가 노출되어 더 이상 익명성이 보장이 안 된다면, 해당 멤버십 인증서는 더 이상 사용할 수 없을 뿐만 아니라 반드시 사용자 퇴출 절차를 밟아서 사용하지 못하도록 해야 한다. 이는 정상적인 사용자에게 있어서 너무 가혹한 처분이며, 시스템의 입장에 있어서도 부담이 될 수밖에 없다.

[6,7]과 같이 지역 연결성을 갖도록 수정된 그룹 서명 기법의 경우, 위와 같은 경우에 서비스 제공자 스스로 문제를 해결할 수 있다. 즉, 지역 연결성을 갖는 그룹 서명의 경우 Open이나 Judge는 오로지 잘못된 행동을 하는 악의적인 사용자를 제지하기 위한 수단으로 사용될 수 있다. 그러나 지역 연결성이 없는 대부분의 수정되지 않은 그룹 서명의 경우 Open이나 Judge는 조금 더 신중하게 사용될 필요가 있다.

그룹 서명 기법이 가질 수 있는 이러한 문제에 대해서 MMO06의 예를 들어 생각해보기로 하자.

3.2. Makita-Manabe-Okamoto-06에서의 Open/Judge의 이해

3.2.1. 익명성이 취소되는 Open/Judge

MMO06^[2]은 선형 암호화 기법을 사용하면서, Judge 기능을 제공해주는 그룹 서명 기법이다. 이 그룹 서명 기법에서는 그룹 공개키 #, 멤버십 인증서 (A,B,x,s,q), 멤버십 인증서 발행키 γ, 익명 철폐키 (ξ₁ ,ξ₂)는 B= h^q, A = Ψ(Bũ(ṽ)^s)^{1/(x + γ)}, w = h^γ, u^ξ₁ =v^ξ₂ = h 와 같은 관계에 이며, Ψ는 #로부터 #으로의 동형 사상(isomorphism)이다. 또한 g₁ = Ψ(h)이다. 최종적으로 서명은 σ = (T₁,T₂,T₃,D₁,D₂,c,s₁,s₂,s₃,s₄,s₅,s₆) 와 같은 형태를 가지고 있다. 여기서 (T₁,T₂,T₃)는 사용자 식별자 A의 선형 암호문이다. 해당 기법을 익명 철폐키의 형태¹⁾에 맞추어 수정한 Open과 Judge는 [그림 1]과 같은 과정으로 이루어진다. 여기서 sig는 B를 사용자의 개인키 sk_i로 서명한 것으로 사용자의 공개키 pk_i로 검증 가능하다.

[그림 1] Makita-Manabe-Okamoto-06의 그룹 서명 기법^[2]

Open과정에서 멤버십 인증서는 (A,B,x,s,q) 중 (A,B,x,s)가 노출된다. 멤버십 인증서에서 멤버십 관리자가 생성하였던 부분이 모두 노출되긴 하지만, q는 사용자 자신이 선택한 비밀로 노출되지 않기 때문에, 여전히 그룹 서명은 서명자만이 생성 가능하다. 즉, 강한 무죄증명성을 가지고 있는 MMO06은 앞서 지적했던 것과 같이 멤버십 인증서를 퇴출하지 않아도 문제가 발생하지 않을 것처럼 보인다. 그러나 이것은 어디까지나 서명자만 그룹 서명을 생성할 수 있다는 것에 대한 확신일 뿐이다. BSZ05 모델^[5]을 따르면 익명성(anonymity)은 공격자에게 멤버십 인증서 발급키 γ를 주었을 때에도 확보되어야 한다. 이는 멤버십 관리자가 공격자가 될 수 있다는 것을 의미한다. MMO06에서는 익명성에 관하여 BSZ05 모델^[5]을 따르지 않지만, 멤버십 인증서 발급키를 공격자에게 주고 있다. 하지만 멤버십 관리자처럼 사용자 데이터베이스에 접근할 수 있는 권한은 주어지지 않고 있다. 즉, MMO06에서 가정하는 공격자는 멤버십 관리자가 아니라 우연히 멤버십 인증서 발급키를 손에 넣은 공격자이다. 이러한 공격자에게 익명 취소 관리자에 의해 어떤 사용자의 멤버십 인증서의 일부 (A,B,x,s)가 노출되었다면, 멤버십 인증서 발급키를 가진 공격자는 [그림 2]와 같이 해당 사용자가 생성한 모든 그룹 서명을 추적할 수 있다.

[그림 2] MMO06에서의 멤버십 인증서 발행키를 가진 공격자에 의한 추적 공격

[그림 2]에서 공격자는

#(1)

이기 때문에 e(g₁,D₂)와 e(Ψ(#)),Bũ(ṽ)^s) e(T₁/A,D₁ )를 각각 구하여 비교함으로써, 주어진 서명의 서명자의 멤버십 인증서의 일부가 (A,B,x,s)임을 확인할 수 있다.

인할 수 있다.

여기서 Ψ(#)) = Ψ(((wh^x)^β)^{1/(γ + x )}) =Ψ((h^γh^x)^{β/(γ + x )}) = Ψ(h^β) =Ψ(h)^β= (g₁)^β이다. 따라서 MMO06에서 Open에 의해 (A,B,x,s)가 노출될 경우 해당 서명자의 모든 그룹 서명들은 멤버십 관리자에게 있어서 더 이상의 익명성을 갖지 않는다고 할 수 있다. 즉, MMO06에서는 어떠한 그룹 서명이 한번 Open되면 해당 그룹 서명에 사용된 멤버십 인증서는 반드시 퇴출되어야 한다.

3.2.2. MMO06의 Open/Judge의 전략

MMO06에서는 Open의 사용에 따라 발생하는 위와 같은 일에 대해서는 특별히 고려되고 있지 않다. 대부분의 그룹 서명에서 Open은 정직하지 않은 사용자에 대한 것으로 널리 받아들이고 있기 때문에 MMO06에 특별한 문제점이 있는 것은 아니다. 그러나 이 논문에서 고려하는 Open이후에서 사용 가능한 멤버십 인증서를 위해서는 MMO06의 Open과 Judge는 다소 수정되어야할 필요가 있을 것으로 보인다. 이를 위하여 MMO06에서 어떠한 Open/Judge의 전략을 사용하는지 이해해야할 것이다.

익명취소 관리자는 Open 과정에서 익명 철폐키 (ξ₁ ,ξ₂)에 대해서 NIZK(Non-Interactive Zero-Knowledge proof)을 수행한다. {R₃ = #, R₄ = # , c =H(⋯, R₃,R₄),s₁ = r₁+cξ₁ ,s₂ = r₂ +cξ₂}이 그에 해당한다. 이는 안전성이 충분히 검증되어 널리 사용되는 NIZK 방식을 익명 철폐키 ξ₁와 ξ₂에 대해서 각각 독립적으로 수행한 것으로, (ξ₁ ,ξ₂) 없이는 생성해낼 수 없다.

다음으로, 익명취소 관리자는 (ξ₁ ,ξ₂)를 이용하여 X₁ = # 과 X₂ = #처럼 계산하였음을 증명하려고 한다. 하지만 저자들은 X₁과 X₂는 익명취소 관리자가 임의로 생성하는 것으로 (ξ₁ ,ξ₂)를 이용하지 않고 전혀 다른 값으로 생성했을 가능성이 있다고 생각하였다. 익명 철폐키 ξ₁와 ξ2의 NIZK이 조작하기 힘든 이유 중 하나는 Judge때 #와 #의 생성에 사용되는 u와 v가 사전에 공개되어 신뢰할 수 있기 때문인데, #와 #의 생성에 사용되는 X₁과 X₂의 경우에는 증명하는 시점에서야 결정되고 증명과 함께 배포된다. s₁과 s₂ 를 (ξ₁ ,ξ₂)의 NIZK와 공유하고 있고 c를 예측하지 못하기 때문에, (X₁,R₁)과 (X₂,R₂)를 조작하기 힘들 것처럼 보이지만, R₁과 R₂를 미리 무작위로 선택하면 X₁과 X₂를 계산하는 시점에서 c는 고정된 값이다. 따라서 X₁←#과 X₂←#로 계산하면 R₁ = #과 R₂ = #인 관계가 성립하도록 할수 있다. 이러한 X₁과 X₂에 대해서 A≠T₃/(X₁⋅X₂ )임은 명백하다.

이러한 조작을 하지 못하도록 하기 위해서, 저자들은 X₁과 X₂이 유효한 값인지 확인하는 과정이 추가적으로 필요했다. 만약 X₁과 X₂가 유효하지 않다는 것은 A′ = T₃/(X₁⋅X₂) 값이 실제로는 A와 다르다는 의미가 된다. A는 Ψ(Bũ(ṽ)^s)^{1/(x + γ)}와로 이루어져 있으므로, (B,x,s)와 γ를 알려줄 수 있다면 T₃/(X₁⋅X₂) = Ψ(Bũ(ṽ)^s)^{1/(x + γ)}임을 확인하도록 할 수 있고, 결과적으로, X₁과 X₂가 (ξ₁ ,ξ₂)로 만들어진 유효한 값임을 확신할 수 있다. 하지만 멤버십 인증서 발행키 γ를 공개할 수 없으므로, e(T₃/(X₁⋅X₂),wh^x) = e(g₁ ,Bũ(ṽ)^s)와 같이 그룹 공개키 중 하나인 w를 이용하여 검증하도록 해야 한다.

여기에 증명을 고의적으로 왜곡하려는 공격자(멤버십 인증서 발행키 γ를 알고 있다)에 대한 고려로써^[5], 서명자의 외부의 서명용 공개키 pk_i와 B의 서명 sig를 추가적으로 공개하여 (B,x,s)가 공격자에 의해서 증명하는 시점에 생성되지 않았음을 보였다. B= A^{′γ + x}/(uv^s)로, 공격자가 무작위로 선택한 R₁과 R₂ 때문에 생성되는 A′로부터 계산해낼 수 있다. 이는 NIZK와는 관계가 없고 오로지 그룹 서명 기법의 비편제성(non-frameability)의 확보 때문에 필요한 것이다.

3.2.3. BBS04로의 Open과 Judge의 이식

BBS04는 MMO06과 다르게 서명의 길이가 짧을뿐만 아니라, 대부분의 연산을 G₁에서 수행하기 때문에 MMO06보다 고속으로 동작한다. 따라서 그룹 서명의 응용 환경에 있어서 BBS04의 사용은 고려될 만 하다. 하지만 앞서 이 논문에서 고려하였던 응용 환경에서는 BBS04는 사용될 수 없을 것처럼 보인다. 왜냐하면 BBS04 자체로는 Open과 Judge를 제공하고 있지 않기 때문이다. 그러나 MMO06과 BBS04는 동일한 선형 암호문을 사용하고 있는 그룹 서명들 이기 때문에, MMO06의 Open과 Judge를 BBS04에 맞도록 수정한 다음 어렵지 않게 사용할 수 있다. 원래의 BBS04에는 Judge기능이 없기 때문에 비편제성을 위한 고려는 필요가 없다.

이렇게 BBS04에 Open/Judge 기능이 생겼다면, 이 논문에서 고려하였던 응용 환경에 사용할 수 있는지 확인해볼 필요가 있다. MMO06과 다르게 BBS04는 서명 내에 D₁과 D₂와 같은 요소가 없기 때문에, 앞서 MMO06에서의 Attack.Trace. MMO06과 동일한 공격은 수행할 수 없다. 그러나 BBS04는 MMO06의 Open을 이용할 경우, 강한 무죄입증성이 없기 때문에 멤버십 인증서 (A,x)가 모두 노출된다. 멤버십 인증서가 노출되면, 다른 누군가는 이를 이용하여 유효한 서명을 생성할 수 있기 때문에, 그 즉시 멤버십 인증서를 폐기해야 한다. 이는 사실상 사용자 퇴출과 다르지 않다.

따라서 MMO06의 Open/Judge를 BBS04에 사용해도, 이 논문에서 원하는 응용 환경에서의 사용은 여전히 불가능하다. 따라서 BBS04를 위해 다른 Open과 Judge를 설계하든가, 아니면 BBS04 자체를 해당 응용 환경에서의 사용을 제한하여야 한다.

IV. 사용자 식별자만을 노출하는 새로운 Open과 Judge

4.1. 정상적인 사용자를 위한 Open과 Judge

이상과 같은 이유에서 MMO06의 Open과 Judge는 자신뿐만 아니라, BBS04에서도 정상적인 사용자의 뜻하지 않은 오류에는 사용될 수 없을 것 같다. 일반적으로 그룹 서명 기법에서 사용자의 식별자를 알아낸다는 의미는 사용자의 실명을 알아낸 것과 동일시되고 있다. 이 또한 정확한 의미에서는 특정 그룹 서명에 대한 식별자만을 알아냈다는 것으로 Open하지 않은 그룹 서명에 대하여 실명이 노출된 것은 아니다. 필요에 따라 Open을 할 수 있고, 특정 그룹 서명의 사용자 식별자가 노출될 수는 있지만, 한 번의 Open이 사용자의 그룹 퇴출로 이어지는 것은 가혹하다. 정상적인 사용자의 뜻하지 않은 오류에 대해서 그룹 서명 기법이 가진 예외처리 방법은 Open밖에 없으므로 반드시 이를 필요로 하지만, 사용자 퇴출로 이어지는 Open이라면 사실상 사용할 수 없다. 따라서 MMO06의 Open과 Judge를 대신하여 사용할 수 있는 새로운 OpenHU 및 JudgeHU가 필요하다.

MMO06의 Open에서 c는 H(R₁,R₂,R₃,R₄)처럼 계산하였기 때문에, X₁과 X₂의 증명 시점에서의 유효성에 문제가 발생하였고, 결국 사용자 식별자 A의 유효성까지 영향을 주어 A가 올바른 값인지 확인하는 과정이 추가적으로 필요했다. X₁과 X₂의 유효성만 확보할 수 있다면, 문제를 쉽게 가져갈 수 있을 것이다.

X₁과 X₂가 R₁과 R₂를 보고 생성된 것이 아님을 보이기 위해서는 간단히 c를 H(X₁,X₂,R₁,R₂,R₃,R₄)로 계산하도록 하면 된다. 앞서 설명했던 것과 같이 s₁과 s₂, 그리고 R₃와 R₄는 익명 철폐키 (ξ₁ ,ξ₂)의 NIZK와 맞물려 원천적으로 조작이 불가능하다. 따라서 X₁과 X₂를 조작하려면, R₁=# , R₂ =#인 관계가 되도록 R1과 R2를 선택할 수 있어야 한다. 그런데 c는 (X₁,R₁)와 (X₂,R₂)가 모두 정해지는 시점에서 결정되고 주어진 서명의 T₁과 T₂는 조작할 수 없으므로, 이는 불가능하다. c와 관계없는 (X₁,R₁)와 (X₂,R₂)를 만드는 유일한 경우는 오로지 X₁= X₂= 1, R₁= #, R₂ = #인 경우인데, 정상적인 서명에 대해서, #= 1 또는 #= 1이 될 확률은 매우 낮을 뿐만 아니라,²⁾ 이는 Judge 과정에서도 쉽게 검출이 가능하다. 따라서 MMO06과 BBS04 둘 모두에 대해서 사용자의 식별자만을 노출하는 [그림 3]과 같은 OpenHU와 JudgeHU를 생각해볼 수 있다.

[그림 3] 정직한 사용자를 위한 Open과 Judge

OpenHU와 JudgeHU는 정상적인 사용자의 실명 정보를 노출하고자 하는 것이 아니므로, MMO06의 Open처럼 사용자의 실명확인을 위한 과정이 없다. MMO06이 Open/Judge 대신 OpenHU/JudgeHU를 사용한다고 해도 비편제성은 여전히 확보 가능하다. 왜냐하면 MMO06에서, 강한 무죄증명성 때문에 어떠한 공격자도 멤버십 인증서를 알 수 없는 정상적인 사용자에 대한 서명은 위조할 수 없으며, 정직한 사용자가 주어진 멤버십 인증서에 다른 A′를 넣어 그룹 서명을 생성할 수도 없다. 앞서 설명한 바와 같은 이유에서 X₁와 X₂는 #와 #이외에 다른 값일 가능성은 없으므로, OpenHU의 결과 A는 언제나 주어진 서명에 암호화된 멤버십 인증서의 식별자이다. 즉, 그룹 서명이 현재 올바르다면 A는 언제나 정직한 사용자의 멤버십 인증서 식별자이다. 우리가 더 확인해 보아야 할 것은 OpenHU와 JudgeHU를 사용할 때, Attack .Trace.MMO06과 같은 공격이 여전히 가능한 가일 것이다.

정리 1. 선형 암호화 기법이 (t′,ε′)-CPA 의미론적(semantically)으로 안전할 때, OpenHU/ JudgeHU를 Open/Judge로 사용하는 선형 암호화 기법 기반의 그룹 서명에 대해서, 어떠한 메시지 m₁과 그에 대한 선형 암호문을 사용하는 그룹 서명 σ₁이 있고, 그에 대한 OpenHU의 결과로써 (A,π)가 주어졌을 때, 어떠한 확률 기반의 다항식 알고리즘 A가 또 다른 메시지 m₂과 그룹 서명 σ₂에 대해서 σ₁과 σ₂가 동일한 사용자에 의해서 서명되었다는 것을 t ≥ t′ -O(q_H)시간 안에 취할 수 있는 이득은 ε ≤ ε′와 같다. 알고리즘 #의 이득은 #로 계산하며, q_H는 랜덤오라클 O^H로의 질의 횟수이다.

증명. 어떠한 알고리즘 #가 t시간 안에 ε만큼의 이득으로 주어진 문제를 해결하는 한다고 할 때, 이를 이용하여 선형 암호화 기법의 IND-CPA를 깨는 또다른 알고리즘 #를 설계할 수 있다.

알고리즘 #는 어떠한 다른 알고리즘 #로부터 선형 암호화 기법에 대한 공개키 (u,v,h)∈{#₂}³를 받는다. 알고리즘 #는 멤버십 인증서 발행키 γ∈Z_p를 무작위로 선택하고, 이에 따라 (u,v,h)를 포함하는 gpk를 생성한다. 예를 들어, MMO06에서는 gpk = (ũ,ṽ,h,u,v,w)를 생성하기 위해서는 w = h^γ를 계산하고, 나머지 (ũ,ṽ)∈_R{#₂}²를 무작위로 선택하면 된다. 알고리즘 R는 임의의 멤버십 인증서 gsk = (A,⋯) 를 생성하고(이는 멤버십 인증서 발행키가 있기 때문에 가능하다), gpk와 gsk를 이용하여 임의로 선택한 메시지 m₁에 대하여 서명 σ₁ = (T₁ ,T₂ ,T₃ ,⋯)을 생성한다. 이 때, A = Ψ(A₀)인 관계에 있다. 알고리즘 R는 무작위로 (c,s₁,s₂)∈_R{#_p}³와 X₁∈_R#₁를 생성하고, X₂ = T₃/(A⋅X₁), R₁ = # , R₂←# , R₃←#, R₄←#로 계산하고, π= (X₁ ,X₂ ,c,s_1,s₂) 로 놓는다. 그 후 알고리즘 R는 랜덤 오라클 O^H에 c = H(X₁,X₂,R₁,R₂,R₃,R₄)가 되도록 프로그램 한다. 알고리즘 R는 알고리즘 # 에게 A₀와 무작위로 선택한 A₁∈_R#₂를 보낸다.

알고리즘 #는 A₀와 A₁중에 하나를 무작위로 선택하여 A_b라하고, 이를 (u,v,h)를 이용하여 선형 암호화한 암호문 C_b= (c₁=u^α ,c₂ =v^β ,c₃= A_bh^{α + β} )를 알고리즘 R에게 전달한다. 알고리즘 R는 이를 이용하여 무작위로 선택한 메시지 m₂에 대한 그룹 서명 σ₂를 생성해야 한다. 이때 σ₂는 C_b를 이용하여 생성해야 하는데, 알고리즘 R는 C_b에 사용된 α와 β를 알 수 없으므로, 정상적인 서명을 생성할 수 없다. 알고리즘 R는 서명의 나머지 요소들을 랜덤하게 채우고 랜덤 오라클 O^H 을 조작하여 해당 서명이 올바르도록 한다. 이는 위와 유사한 과정을 통해 이루어질 수 있다. 단, MMO06의 경우 e(Ψ(c₃),D_1|σ2) = e(g₁,D_2|σ2)인 관계가 되도록 D_1|σ2과 D_2|σ2를 조작해야 하는데, 무작위로 선택한 δ←_R#_p에 대해서 D_1|σ2=h^δ , D_2|σ2=#로 놓으면 된다.³⁾ 이제 알고리즘 #는 (gpk,(m₁,σ₁), (A₀,π),(m₂,σ₂))를 알고리즘 A에 입력하고 알고리즘 #를 동작시킨다

랜덤 오라클 O^H는 알고리즘 #가 조작한 두 개의 질의에 대해서만 저장된 값을 응답으로써 돌려주고, 나머지 질의에 대해서는 무작위 값을 선택하여 돌려주되, 이를 기록하여 동일한 질의가 두 번 이상 도착했을 때에는 같은 응답을 주도록 한다. 알고리즘 #는 자신이 원하는 언제든 랜덤 오라클 O^H 에 질의를 할 수 있다.

알고리즘 #는 t시간 안에 (1/2+ε)의 확률로 두 서명이 동일한 사용자에 의해 생성되었는지에 대해서 0 또는 1로 응답할 것이다. 만약 알고리즘 #가 다른 사용자에 의해서 서명되었다는 의미로 0을 돌려주었다면 알고리즘 R는 자신이 받은 C_b가 A₁의 암호문이라는 의미로 1을 알고리즘 #에게 돌려준다. 만약 반대로 알고리즘 #가 1을 돌려주었다면 알고리즘 #는 C_b가 A₀의 암호문이라는 의미로 0을 알고리즘 #에게 돌려준다.

이 과정에서 알고리즘 #는 (A₀,π)와 (m₁,σ₁)과 (m₂,σ₂)를 검증하는 과정이 필요하다. 이 중 (m₁,σ₁) 는 정상적으로 생성하였으므로 항상 유효하지만, 나머지 (A₀ ,π)와 (m₂ ,σ₂)는 그렇지 않다. 알고리즘 #가 램덤 오라클 없이 둘 중 하나라도 π와 σ₂에 포함된 해시 함수를 계산했을 수도 있다면, 이 둘이 잘못된 것을 알고 알고리즘 #는 중간에 연산을 중단할 것이다. 그러나 이 확률은 1/p보다 작으므로 무시할 만하다. 또한 이 과정에서 알고리즘 A는 q_H만큼의 질의를 랜덤 오라클 O^H에 보냈을 것이고, 이 시간은 O(q_H)로 표현 가능하다. 따라서 만약 선형 암호화 기법이 (t′,ε′)-CPA 안전하다면, ε′ ≥ ε와 같으며, t′ ≤ t +O(q_H )와 같다. □

위 증명은 MMO06에만 제한된 것이 아니며, 선형 암호문을 사용하는 대부분의 그룹 서명에 유효하므로, BBS04에도 적용 가능하다. 따라서 OpenHU와 JudgeHU는 멤버십 인증서 발행키를 손에 넣은 공격자에게 Attack.Trace와 같은 공격에 안전하다.

4.2. 동일 식별자를 갖는 그룹 서명들을 위한 일괄 Open/Judge

3.1절에서의 시나리오에 따르면 GM은 같은 사용자 식별자를 갖는 복수의 서명을 동시에 Open해야할 필요도 있다. n개의 선형 암호문을 사용하는 그룹 서명에 대해서 Open과 Judge를 수행하는 가장 단순한 방법은 GM과 서비스 제공자가 4.1절과 같은 과정을 n번 반복하는 것이다. ξ₁과 ξ₂의 증명과 확인 값 c를 공유함으로써 약간의 연산과 통신비용을 줄일 수 있지만, 큰 차이는 없다. 이러한 환경에서 다음과 같은 연산과 공간에 있어서 충분한 이득을 주는 Open과 Judge 구조를 생각해볼 수 있다.

GM은 위 Open을 수행해서 같은 사용자 식별자를 가진 서명을 골라낸 뒤, Judge를 위한 증명 π를 BatchProof를 통해서 생성해낸다. 이러한 과정을 거쳐 선택된 그룹 서명들 {σ₁ ,σ₂ ,⋯,σ_n}과 이들의 식별자 A, 그리고 증명  π를 서비스 제공자에게 전송해주면, 서비스 제공자는 BatchJudge를 통해서 서명들의 식별자가 A가 올바른지 확인한다.

[그림 4] 정직한 사용자의 예외 처리를 위한 Open/BatchProof/BatchJudge

BatchProof의 동작 방식을 간략히 설명하면, 다음과 같다. 모두 같은 식별자를 가진 서명에 대해서

#(2)

인 관계를 유지한다. (Y₁ ,Y₂ ,Y₃)는 서명이 공개되어 있어 이를 조작할 수 없기 때문에, Aⁿ = Y₁/(#)를 증명하는 것은 4.1절과 같은 방식으로 증명될 수 있다. 그러나 이는 정확한 의미에서 그룹 서명들{σ₁ ,σ₂ ,⋯,σ_n}의 식별자의 평균이 A와 같다는 것을 증명한 것으로 GM은 동일하지 않은 식별자를 가진 서명들을 특정한 사용자의 식별자인 것처럼 위조하거나, 무작위로 선택한 서명들의 평균을 구해 A로 제시할 수 있다. 이를 막기 위해서, 각각의 서명의 (T_1,i,T_2,i,T_3,i)에 무작위 상수 bi를 곱하여 (E₁ ,E₂ ,E₃) 를 만들어 사용하고, 무작위로 t번째 그룹 서명을 선택하여 4.1절과 같은 증명을 수행한다. 그러나 무작위로 선택되는 {b_i}_{i = 1..n}와 t에 따라 GM은 여전히 수식에 맞는 그룹 서명을 선택할 수 있으므로, 이를 방지하기 위해서 PRNG의 입력으로 그룹 서명{σ₁ ,σ₂ ,⋯,σ_n}을 사용하여 {b_i}_{i = 1..n}와 t를 구하도록 한다. {b_i}_i = 1..n와 t는 어떠한 그룹 서명이 선택하기 전에는 알 수 없고, 동일하지 않은 식별자를 가진 그룹 서명들이 E₁/(#²⁾가 (T_3,t/(X₃X₄))^l 와 동일한 값이 되도록 하기 어렵다.

이러한 Open/BatchProof/BatchJudge도 [정리 1]과 그 증명과 동일하게 멤버십 인증서 발행키를 가진 공격자에게 추적되지 않음을 보일 수 있다. 이는 단지 (A, π)를 바꾸는 것으로,  π의 유효성을 믿게 하기 위하여 프로그램 가능한 랜덤 오라클을 이용할 수 있다.

4.3. 강한 무죄입증성의 필요성

앞서 살펴보았던 것처럼 MMO06의 경우 강한 무죄입증성은 멤버십 인증서 발급키를 가진 공격자에게 별다른 의미가 없었지만, BBS04에서와 같은 예를 살펴보았을 때, 강한 무죄입증성은 중요한 역할을 한다. 이 논문에서는 MMO06과 마찬가지로 멤버십 인증서 발급키만을 가진 공격자를 우선 가정하지만, 멤버십 관리자의 경우 과거 자신이 발행했던 정보를 모두 가지고 있을 수 있다. 만약 멤버십 관리자가 공격자가 된다면, 이 논문에서 제안하는 것과 같은 OpenHU/JudgeHU를 사용한다고 해도, 식별자 A로부터 멤버십 인증서 중 사용자만 알고 있는 비밀키를 제외한 모든 멤버십 인증서가 노출된다. 강한 무죄입증성이 없을 때, 이는 곧 멤버십 인증서의 노출을 의미한다.

이러한 고민은 결국 다시 멤버십 관리자를 신뢰할 수 있는가 없는가의 문제로 되돌아가, 강한 무죄입증성이 없는 경우 싫어도 멤버십 관리자를 신뢰해야만 한다. 이는 보안을 바라보는 보수적 입장에서 그룹 서명 기법에는 강한 무죄입증성이 필요함을 역설한다.

V. 결론

이 논문에서는 정상적인 사용자들에게 발생할 수 있는 뜻하지 않은 예외 상황의 처리를 위해서 선형 암호문을 이용하는 그룹 서명 기법의 Open과 Judge가 어떻게 사용되어야하는 지 살펴보았다. MMO06과 같은 그룹 서명의 경우 정상적인 사용자들이 뜻하지 않은 오류로 인하여 그룹에서 퇴출당할 수 있음을 확인하였고, BBS04에 MMO06의 Open/Judge를 적용하였을 때에도 마찬가지였다. 이를 위한 이 논문에서는 사용자의 식별자만을 노출하는 OpenHU과 JudgeHU에 대해서 제안하였으며, 이러한 OpenHU/JudgeHU를 사용했을 때, 사용자의 그룹 서명이 멤버십 인증서 발행키를 가진 공격자에게도 추적되지 않음을 랜덤 오라클 모델에서 증명하였다. 여기에 더해, 복수의 동일한 사용자 식별자의 그룹 서명들을 빠르게 처리하기 위한 일괄 Open/BatchProof/ BatchJudge를 추가적으로 제안하였다.

이처럼 그룹 서명 기법은 이상적인 환경을 가정하고 만들어졌기 때문에, 현실 세계를 충실히 고려하지 못한 측면이 많이 존재한다. 따라서 현실 세계의 응용 환경을 실제로 고려하였을 때, 그룹 서명 기법에 나타날 수 있는 문제점을 고찰해보고 이를 해결할 수 있는 연구가 지속되어야할 것이다.