속성 기반 암호화(ABE, Attribute-Based Encryption)

1. 개요

가. 정의

사용자의 신원(ID)이 아니라 "속성(attribute)의 집합"과 그 속성들에 대한 "접근 정책(access policy)"의 일치 여부로 복호화 권한을 결정하는 공개키 암호 방식. 암호문 또는 복호화 키에 "부서=기획 AND 직급≥팀장"과 같은 논리식을 내장하여, 정책을 만족하는 속성을 가진 사용자만 암호문을 열 수 있도록 한다. 암호화 한 번으로 다수의 수신자를 정책으로 지정하는 1:N 세밀접근제어(fine-grained access control) 암호라는 점에서 전통 공개키 암호와 근본적으로 구별된다.

ABE라는 이름은 "누구에게(who)"가 아니라 "어떤 자격을 갖춘 자에게(what properties)" 데이터를 공개할지를 암호 자체에 적어 넣는다는 발상에서 왔다. 전통적인 공개키 암호(RSA·ECC)는 특정 수신자의 공개키로 암호화하므로, 수신자가 누구인지를 송신 시점에 알아야 하고 수신자가 열 명이면 열 번 암호화해야 한다. ABE는 수신자의 실명을 전혀 모르는 채 "이러이러한 속성을 가진 사람"이라는 추상적 자격으로 암호화하며, 복호화 가능 집합을 정책식으로 한 번에 지정한다. 즉 ABE는 접근제어(access control)를 암호 연산 자체에 녹여 넣은 암호-접근제어 융합 기술이다.

ABE의 주요 특징을 정리하면 다음과 같다. 첫째, 세밀한 정책 표현으로 AND·OR·임계값(threshold, k-of-n) 등 논리식을 암호문에 담을 수 있다. 둘째, 담합 저항성(collusion resistance) 으로 각자 혼자서는 정책을 만족하지 못하는 여러 사용자가 키를 합쳐도 복호화할 수 없다. 셋째, 1:N 효율성으로 수신자 수와 무관하게 한 번만 암호화하면 된다. 넷째, 이 모든 강점의 대가로 쌍선형 페어링(bilinear pairing)에 기반한 높은 연산 비용과 속성 변경·탈퇴 시의 폐지(revocation) 난제를 안는다. 이 네 특징의 균형을 설계하는 것이 ABE 활용의 본질이다.

이 특징들은 ABE를 "데이터 중심 보안([[dspm]])"과 "제로트러스트"의 암호학적 토대로 자리매김하게 한다. 네트워크 경계가 사라지고 데이터가 어디로든 흘러가는 환경에서, 보호는 데이터가 놓인 장소(서버·네트워크)가 아니라 데이터 그 자체에 내장되어야 한다. ABE는 접근정책을 암호문에 붙여 "데이터가 스스로 자기 열람 자격을 들고 다니게" 만들므로, 데이터가 어느 저장소로 이동하든 정책이 따라붙는 데이터 자기보호(self-protecting data) 를 실현한다. 이는 "절대 신뢰하지 말고 항상 검증하라"는 제로트러스트 원칙을 데이터 계층에서 암호로 강제하는 수단이 된다.

나. 등장 배경 및 필요성

클라우드·협업 환경이 보편화되면서 데이터는 더 이상 소유자가 통제하는 서버에만 머물지 않고, 신뢰할 수 없는 제3자 인프라(클라우드 스토리지)에 올려 다수의 이해관계자가 공유하는 형태로 바뀌었다. 이때 전통적 접근제어(ACL·RBAC)는 서버(참조 모니터)가 정직하게 정책을 집행한다는 전제에 의존한다. 그러나 클라우드 사업자가 침해당하거나 내부자가 악의를 품으면, 서버에 평문으로 저장된 데이터는 접근제어 목록을 우회해 그대로 유출된다. 보호의 신뢰 경계가 "서버를 믿어야만 성립"한다는 구조적 약점이 있는 것이다.

이 공백을 메우려는 가장 단순한 시도가 데이터를 암호화해 올리는 것이지만, 여기서 곧바로 열쇠 배포의 딜레마가 생긴다. 특정 수신자 공개키로 암호화하면 공유 대상이 바뀔 때마다 재암호화·재배포가 필요하고, 대칭키를 공유하면 한 사람만 유출돼도 전체가 뚫린다. 수신자가 수백 명이고 자격 조건(부서·직급·프로젝트)이 수시로 바뀌는 조직에서는 이 방식이 사실상 운영 불가능하다.

이 운영 불가능성은 수치로도 분명하다. 수신자가 N명이고 그중 일부만 열람 가능한 문서를 전통 PKE로 공유하면, 접근 집합이 바뀔 때마다 평균 O(N)회의 재암호화가 필요하고, 문서가 M개면 최악의 경우 O(N·M)의 키 관리 폭발이 일어난다. 부서·직급·프로젝트가 교차하는 조직에서는 접근 조합이 조합폭발(combinatorial explosion)을 일으켜, 관리자가 "누가 무엇을 볼 수 있는가"를 추적하는 것조차 불가능해진다. 바로 이 지점이 속성 기반 사고가 필요한 이유다.

ABE는 "암호화 시점에 수신자를 몰라도, 자격 조건만으로 복호화 집합을 지정"함으로써 이 딜레마를 정면으로 해소한다. 데이터를 "인사팀 AND 과장 이상"이라는 정책으로 한 번 암호화해 클라우드에 올려 두면, 그 조건을 만족하는 속성 키를 가진 직원은 누구나 열 수 있고, 조건을 벗어난 신규 인력에게는 원문이 보이지 않는다. 서버는 정책을 집행하지 않고 단지 암호문을 저장·전달할 뿐이므로, 서버를 신뢰하지 않아도 접근제어가 성립한다. 이 때문에 ABE는 암호학적 접근제어(cryptographic access control) 와 프라이버시 강화기술(PET) 의 핵심 수단으로, [[homomorphic-encryption]]·[[multi-party-computation]] 등과 함께 "신뢰 최소화" 데이터 보호 설계의 한 축으로 평가된다.

2. 동작 원리와 구조

가. 전체 구조

flowchart LR
  AA["속성기관 AA(Attribute Authority)<br/>마스터키 MSK / 공개파라미터 PK 생성"] -->|"PK"| ENC["암호화자(Data Owner)"]
  AA -->|"속성집합 S에 대한 비밀키 SK"| USER["복호화자(User)"]
  ENC -->|"정책 P로 암호화한 CT"| STORE["클라우드 스토리지(Honest-but-Curious)"]
  STORE -->|"암호문 CT"| USER
  USER -->|"S가 P를 만족하면 Dec 성공"| OUT["평문 m"]

ABE 시스템은 네 가지 알고리즘 Setup → KeyGen → Encrypt → Decrypt로 구성된다. 먼저 속성기관(AA, Attribute Authority) 이 Setup으로 시스템 공개파라미터 PK와 마스터비밀키 MSK를 만든다. PK는 공개되어 누구나 암호화에 쓰고, MSK는 AA만 보관한다. 사용자가 등록하면 AA는 그 사용자의 속성 집합 S(예: {인사팀, 과장, 2026년입사})에 대응하는 속성 비밀키 SK 를 KeyGen(MSK, S)로 발급한다.

데이터 소유자는 Encrypt(PK, m, P) 로 평문 m을 접근정책 P와 함께 암호화해 암호문 CT를 만들어 클라우드에 올린다. 복호화자는 자신의 SK로 Decrypt(CT, SK)를 시도하는데, 자신의 속성 집합 S가 정책 P를 만족할 때에만 평문을 얻는다. 여기서 핵심은 클라우드(저장 주체)가 정책 판단에 전혀 관여하지 않는다는 점이다. 정책 집행이 서버의 로직이 아니라 암호 수학 자체에 내장되어 있어, 서버가 악의적이어도 정책을 어기고 데이터를 열어 줄 수 없다.

ABE의 안전성에서 가장 중요한 성질은 담합 저항성이다. 예컨대 정책이 "인사팀 AND 과장"일 때, "인사팀"만 가진 A와 "과장"만 가진 B가 각자의 SK를 합치더라도 복호화에 실패하도록 설계된다. 이는 NIST IR 8450이 ABE의 본질로 꼽는 특성으로, 각 사용자의 키에 사용자별 난수(randomization) 를 심어 서로 다른 사용자의 키 조각이 수학적으로 결합되지 않게 만듦으로써 달성된다. 이 난수화가 없으면 ABE는 단순한 속성별 키 꾸러미에 지나지 않으며, ABE를 다른 다중수신자 암호와 구별 짓는 결정적 지점이 바로 이 담합 저항성이다.

구체적 사례로 종합병원의 전자의무기록(EHR) 공유를 들어 보자. 어느 환자의 검사 결과를 "(주치의 AND 순환기내과) OR (병원장)"이라는 정책으로 암호화해 클라우드 EHR에 올렸다고 하자. 순환기내과 소속이지만 그 환자의 주치의가 아닌 의사 C와, 다른 과 주치의 D가 자신들의 속성 키를 합쳐도 — C는 "순환기내과"만, D는 "주치의"만 가지므로 — 첫 번째 절(clause)의 AND를 한 사람 안에서 만족시키지 못해 복호화에 실패한다. 반면 "주치의"와 "순환기내과"를 한 사람 안에 동시에 보유한 담당의, 또는 "병원장" 속성을 가진 원장만이 열람할 수 있다. 서버(클라우드 EHR)는 이 판단에 전혀 개입하지 않으며, 설령 DB가 통째로 유출돼도 정책을 만족하지 못하는 공격자에게는 암호문만 남는다. 이처럼 "자격의 조합을 한 주체 안에서 요구"하는 능력이 ABE가 의료·금융 같은 고규제 영역에서 매력적인 이유다.

나. CP-ABE와 KP-ABE — 정책의 위치

flowchart TB
  subgraph CP["CP-ABE(Ciphertext-Policy)"]
    CPC["암호문 CT = 데이터 + 접근정책 P<br/>'부서=인사 AND 직급≥과장'"]
    CPK["사용자키 SK = 속성집합 S<br/>{인사, 과장}"]
    CPK -->|"S가 P를 만족?"| CPC
  end
  subgraph KP["KP-ABE(Key-Policy)"]
    KPC["암호문 CT = 데이터 + 속성집합 S<br/>{장르=뉴스, 날짜=2026}"]
    KPK["사용자키 SK = 접근정책 P<br/>'장르=뉴스 OR 날짜=2026'"]
    KPK -->|"P가 S를 만족?"| KPC
  end

ABE는 "정책식을 어디에 담느냐"에 따라 크게 두 갈래로 나뉜다. CP-ABE(Ciphertext-Policy ABE) 는 접근정책을 암호문에 담고 속성을 사용자 키에 담는다. 즉 데이터 소유자가 암호화하면서 "누가 열 수 있는가"를 직접 정책으로 지정하므로, 소유자가 접근 권한을 통제하는 직관적 모델이다. 조직의 문서 공유, 전자의무기록(EHR) 공유처럼 데이터 생산자가 공개 대상을 정하는 상황에 적합하다. Bethencourt·Sahai·Waters(2007)의 구성이 대표적이며, ETSI 표준은 이를 CP-WATERS-KEM·CP-FAME-KEM 등으로 규격화하였다.

반대로 KP-ABE(Key-Policy ABE) 는 속성을 암호문에, 접근정책을 사용자 키에 담는다. 콘텐츠에는 그 속성(장르·날짜 등)만 태깅해 암호화하고, 사용자에게는 "뉴스이면서 2026년"처럼 열람 가능 범위를 정의한 정책 키를 발급한다. 로그 감사, 방송·콘텐츠 구독처럼 중앙 기관이 사용자별 열람 범위를 부여하는 상황에 어울린다. Goyal·Pandey·Sahai·Waters(2006)의 GPSW 구성이 효시이며, 두 방식의 차이는 단순한 대칭이 아니라 "접근 통제의 주도권이 데이터 생산자에게 있는가(CP), 키 발급 기관에 있는가(KP)"라는 거버넌스 모델의 차이로 이어진다는 점이 실무상 중요하다.

실무 채택 비중으로 보면 CP-ABE가 압도적으로 널리 쓰인다. 그 이유는 직관성에 있다. 데이터를 올리는 사람이 "이 문서는 과장급 인사팀만"이라고 암호화 시점에 스스로 공개 범위를 명시하는 모델이, 조직의 문서 보안·클라우드 공유 사고 흐름과 그대로 맞아떨어지기 때문이다. KP-ABE는 반대로 데이터에 붙는 속성이 고정적이고(예: 방송 콘텐츠의 장르·방영일), 열람 자격을 중앙에서 유연하게 조정하고 싶은 구독형 서비스에 적합하다. 따라서 CP냐 KP냐의 선택은 성능 비교가 아니라 "누가 접근을 결정해야 하는가"라는 업무 거버넌스 질문에서 출발해야 한다.

구분	CP-ABE	KP-ABE
정책 위치	암호문(CT)	사용자 키(SK)
속성 위치	사용자 키(SK)	암호문(CT)
통제 주도권	데이터 소유자(암호화자)	키 발급 기관
대표 구성	BSW07, FAME	GPSW06
전형적 활용	문서·EHR 공유, 조직 접근제어	콘텐츠 구독, 로그 감사, 방송

다. 접근구조와 쌍선형 페어링

ABE에서 정책은 접근구조(access structure) 로 표현되며, 실무 구현에서는 접근트리(access tree)나 선형 비밀분산(LSSS, Linear Secret Sharing Scheme) 행렬로 부호화된다. 접근트리의 내부 노드는 AND(2-of-2)·OR(1-of-2)·임계값(k-of-n) 게이트가 되고 잎 노드는 개별 속성이 된다. 복호화는 사용자의 속성이 채우는 잎에서 출발해 루트의 비밀값을 복원할 수 있는지를 따지는 비밀분산 복원 문제로 환원된다. 이 때문에 속성이 많고 정책이 복잡할수록 복호화 비용이 선형 이상으로 증가한다.

ABE의 안전성은 대부분 쌍선형 페어링(타원곡선 위의 쌍선형 사상 e: G×G→G_T)과 그 위에서 정의되는 어려운 문제(예: Decisional BDH)에 의존한다. 페어링은 암호문의 속성 요소와 키의 속성 요소를 "짝지어" 비밀값을 재조합하는 핵심 연산인데, 바로 이 페어링 연산이 RSA·ECC 대비 수십~수백 배 느려 ABE의 성능 병목이 된다. 예컨대 속성 20개짜리 정책의 복호화에 페어링 수십 회가 필요하며, 이는 IoT 센서처럼 연산 자원이 빈약한 기기에서 ABE 채택을 가로막는 구체적 수치상의 장벽이 된다. 이를 완화하려고 FAME(2017)처럼 상수 개수의 페어링만 쓰는 고속 구성, 복호화 연산을 클라우드에 위임하는 아웃소싱 복호화(outsourced decryption) 등이 제안되어 왔다.

여기서 반드시 짚어야 할 설계 원칙은 ABE를 데이터 본문 암호화에 직접 쓰지 않는다는 점이다. 페어링 연산은 느리므로, 실무에서는 대용량 평문을 빠른 대칭키(AES)로 암호화하고 그 대칭키만 ABE로 봉인하는 KEM/DEM(하이브리드) 구조를 쓴다. ETSI 표준이 ABE를 "암호화(encryption)"가 아니라 "키 캡슐화(KEM)" 스킴으로 규격화한 까닭이 바로 이것이다. 즉 ABE는 접근정책에 따라 "대칭키라는 열쇠"를 나눠 주는 암호학적 열쇠 분배기 역할을 맡고, 실제 데이터는 그 열쇠로 연 AES가 복호화한다. 이 구조는 성능을 확보하는 동시에, 정책이 바뀌어도 본문 전체가 아니라 작은 캡슐만 재암호화하면 되도록 운영 부담을 줄인다.

라. 구성요소와 암·복호화 절차

ABE 시스템의 구성요소는 네 당사자와 네 알고리즘으로 요약된다. 당사자는 ① 공개파라미터·마스터키를 만들고 속성 키를 발급하는 속성기관(AA), ② 정책으로 데이터를 암호화하는 데이터 소유자, ③ 속성 키로 복호화를 시도하는 사용자, ④ 암호문을 보관·전달하되 정책 판단에는 관여하지 않는 저장소(클라우드) 다. 저장소를 "정직하지만 호기심 많은(honest-but-curious)" 주체로 가정한다는 점이 ABE 신뢰모델의 핵심으로, 저장소는 규약은 따르되 내용을 엿보려 할 수 있다고 보고 그래도 안전하도록 설계한다.

절차는 다음과 같이 흐른다. 첫째 Setup 단계에서 AA가 보안 파라미터를 입력받아 전역 공개파라미터 PK와 마스터비밀키 MSK를 생성한다. 둘째 KeyGen 단계에서 사용자가 신원·자격을 제출하면 AA가 검증 후 그 속성 집합 S에 묶인 비밀키 SK를 발급하는데, 이때 사용자별 난수를 심어 담합을 차단한다. 셋째 Encrypt 단계에서 데이터 소유자가 접근정책 P(CP-ABE 기준)를 접근구조로 부호화해 평문을 봉인한 암호문 CT를 만들고 저장소에 올린다. 넷째 Decrypt 단계에서 사용자가 자신의 SK 속성이 CT의 정책 P를 만족하면 페어링 연산으로 비밀값을 복원해 평문을 얻고, 그렇지 않으면 실패한다.

이 절차에서 눈여겨볼 점은 Encrypt와 KeyGen이 시간적으로 독립이라는 것이다. 데이터 소유자는 미래에 어떤 사용자가 가입할지 모르는 채 정책만으로 암호화하고, 사용자는 나중에 가입해 키를 받는다. 양자가 공유하는 것은 오직 AA의 공개파라미터뿐이며, 이 비동기성이 "수신자를 몰라도 되는" ABE의 운영 유연성을 뒷받침한다.

3. 핵심 난제와 해법 — 폐지·다기관·키 위탁

ABE를 실제 시스템에 올릴 때 반드시 부딪히는 세 가지 난제가 있으며, 각각은 기술사 답안에서 "왜 단순 적용이 어려운가"를 설명하는 핵심 논점이다.

가. 속성 폐지(Revocation) — 직원이 퇴사하거나 직급이 바뀌면 그가 가진 속성 키를 무효화해야 한다. 그러나 ABE 키는 특정 수신자가 아니라 "속성"에 묶여 있어, 한 사람의 "과장" 속성만 콕 집어 회수하기가 어렵다. 해법으로는 속성에 유효기간을 넣어 주기적으로 키를 갱신하는 시간 기반 폐지, 유효 사용자 목록으로 암호문을 갱신하는 직접 폐지, 비폐지 증명을 결합하는 방식 등이 있으나, 모두 키 재배포나 암호문 재암호화 비용을 수반한다.

폐지가 어려운 근본 이유는 ABE의 장점과 단점이 동전의 양면이기 때문이다. "수신자를 몰라도 속성으로 암호화한다"는 1:N 효율성이 역으로 "누구의 어떤 속성을 회수해야 하는지 암호문이 모른다"는 폐지 난점을 낳는다. 즉시 폐지를 추구하면 사용자가 접근할 때마다 중앙 서버 조회가 필요해 ABE의 탈중앙·오프라인 이점이 희석되고, 성능을 지키려 주기적 재키잉으로 타협하면 폐지 반영에 지연이 생긴다. 폐지는 ABE 상용화의 최대 걸림돌로, 완벽한 즉시 폐지와 성능을 동시에 만족하는 범용 해법은 아직 연구 단계다.

나. 다기관 ABE(Multi-Authority ABE) — 단일 AA가 모든 속성을 발급하면 그 AA가 단일 장애점이자 과도한 신뢰 집중점이 된다. 현실에서 "부서" 속성은 인사부가, "보안등급" 속성은 보안팀이, "자격증" 속성은 외부 인증기관이 발급하는 것이 자연스럽다. Chase(2007), Lewko-Waters(2011)의 탈중앙 다기관 ABE는 서로 신뢰하지 않는 여러 기관이 독립적으로 속성 키를 발급하면서도 담합 저항성을 유지하도록 설계한다.

다기관 구성의 어려움은 "기관들이 사전에 조율하지 않고도 하나의 정책을 함께 집행"해야 한다는 데 있다. 서로 다른 기관이 발급한 속성 키 조각들이 한 사용자 안에서는 결합되어야 하지만, 다른 사용자와는 결합되지 않아야(담합 저항) 한다. 이를 위해 사용자 전역식별자(GID)를 매개로 키를 묶는데, 역설적으로 이 GID가 여러 기관에 공유되면 "어느 사용자가 어떤 속성을 받았는지"가 드러나 프라이버시가 침해될 수 있다. Lewko-Waters 구성은 GID를 해시로 은닉해 이 문제를 완화하지만, 실무에서는 기관 간 거버넌스·책임 소재 합의가 기술만큼이나 중요한 과제가 된다.

다. 키 위탁(Key Escrow) — AA는 MSK를 쥐고 있으므로 원리상 임의 사용자의 키를 생성해 모든 암호문을 복호화할 수 있다. 이 "전능한 기관" 문제는 ABE를 공공·의료 영역에 적용할 때 신뢰 문제를 일으킨다. 해법으로 키 생성을 두 기관으로 분리(AA와 중앙기관)하거나, 사용자가 자신의 비밀 성분을 더해 AA조차 완전한 키를 모르게 하는 에스크로 프리(escrow-free) 구성이 연구된다.

키 위탁 문제는 전통 PKI의 "CA가 사설키를 모른다"는 원칙과 대비하면 그 심각성이 분명해진다. PKI에서는 사용자가 자기 키쌍을 만들어 공개키만 인증받으므로 CA가 서명 위조는 가능해도 복호화는 못 한다. 반면 기본형 ABE의 AA는 복호화 키 자체를 발급하므로 "누구의 데이터든 열 수 있는" 권한을 구조적으로 보유한다. 따라서 ABE를 공공·국방에 쓰려면 이 전능성을 반드시 제도·기술로 제약해야 하며, 이것이 ABE 도입 심사에서 가장 먼저 검증되는 신뢰 요건이 된다. 요컨대 이 세 난제는 서로 얽혀 있어 — 다기관으로 가면 폐지와 키위탁 설계가 더 복잡해진다 — ABE 아키텍처 설계는 결국 이 삼각 트레이드오프를 조율하는 작업이 된다.

4. 비교 — 유사 접근제어·암호 기술과의 차이

ABE를 RBAC·IBE·전통 공개키 암호와 견주면 그 위치가 분명해진다. RBAC(역할기반 접근제어) 는 접근제어를 서버 로직으로 집행하므로 서버를 신뢰해야 하지만 ABE는 암호로 집행해 서버 불신 하에서도 성립한다. 다만 RBAC는 정책 변경·감사·폐지가 즉각적이고 저렴한 반면 ABE는 암호 연산 비용과 폐지 난제를 안으므로, 둘은 대체재가 아니라 "민감 데이터는 ABE로 봉인, 운영 통제는 RBAC로" 라는 계층 결합이 현실적이다.

개념적으로 ABE는 접근제어 모델의 진화 계보에서 ABAC(속성기반 접근제어)의 암호학적 구현으로 이해하는 것이 정확하다. ABAC가 "주체·자원·환경의 속성을 평가해 접근을 결정하는 정책 모델"이라면, ABE는 그 속성 평가를 참조 모니터라는 신뢰 컴포넌트가 아니라 암호 연산 자체가 수행하도록 만든 것이다. 바꿔 말해 ABAC가 "정책을 어떻게 기술할 것인가"의 논리 모델이라면, ABE는 "그 정책을 신뢰할 서버 없이 어떻게 강제할 것인가"의 메커니즘이다. 따라서 성숙한 아키텍처는 ABAC로 정책을 표준 기술(예: XACML)하고, 그중 최고 민감 자원의 집행을 ABE로 암호학적으로 못박는 식의 역할 분담을 택한다.

IBE(신원기반 암호) 는 "이메일 주소=공개키"처럼 단일 신원 문자열로 암호화하는데, ABE는 이를 "속성들의 논리식"으로 일반화한 것으로 볼 수 있다(실제로 ABE의 효시인 Sahai-Waters 2005 논문 제목이 "Fuzzy Identity-Based Encryption"이다). 즉 IBE가 1:1 지정이라면 ABE는 정책 기반 1:N 지정이다. 브로드캐스트 암호도 다수 수신자를 다루지만 수신자 목록을 명시적으로 나열하는 반면, ABE는 수신자를 몰라도 속성 조건만으로 집합을 정의한다는 점에서 표현력과 운영 유연성이 앞선다.

이 차이가 실무적 함의로 이어지는 지점은 "조직 변화에 대한 내성"이다. 전통 PKE나 브로드캐스트 암호로 "기획팀 전원"에게 문서를 공유하면, 신규 입사자가 생길 때마다 그의 공개키로 다시 암호화하거나 수신자 목록을 갱신해야 한다. ABE로 "부서=기획"이라는 정책으로 한 번 암호화해 두면, 이후 입사해 "기획" 속성 키를 받은 직원은 기존 암호문을 손대지 않아도 자동으로 열람 권한을 얻는다. 접근 주체의 명단이 아니라 자격의 정의로 암호화하기에, 사람이 드나드는 동적 조직에서 암호문의 수명이 길어지는 것이다. 이 "정책 영속성"이 ABE가 대규모·장기 데이터 공유 설계에서 갖는 핵심 운영 이점이다.

기술	집행 주체	수신자 지정 방식	서버 신뢰 전제	폐지 용이성
RBAC/ACL	서버(참조 모니터)	역할·목록	필요(높음)	쉬움(즉시)
전통 PKE(RSA)	암호	특정 공개키 1인	불필요	키 폐기
IBE	암호	신원 문자열 1인	불필요(부분 위탁)	어려움
ABE	암호	속성 정책(1:N)	불필요	어려움(난제)

5. 심화 — 표준화 동향과 포스트 양자

ABE의 발전 계보를 간략히 짚으면, 2005년 Sahai-Waters의 Fuzzy IBE가 "오차를 허용하는 속성 매칭"으로 씨앗을 뿌렸고, 2006년 GPSW가 KP-ABE로, 2007년 BSW가 CP-ABE로 임의의 접근구조를 지원하며 기본 틀을 완성했다. 이후 2011년 Lewko-Waters의 탈중앙 다기관 구성, 2017년 FAME의 고속·실용 구성으로 이어지며 "이론적 가능성"에서 "구현 가능한 도구"로 성숙해 왔다. 이 20여 년의 궤적은 성능·폐지·신뢰분산이라는 실용화 과제를 하나씩 메워 온 과정으로 읽을 수 있다.

ABE는 이처럼 학계 중심으로 발전해 왔으나, 최근 국제 표준화가 진전되며 산업 적용의 토대가 마련되고 있다. 가장 앞선 것은 ETSI TC CYBER로, 요구사항 문서 TS 103 458(2018)에 이어 ETSI TS 103 532 V1.2.1(2021) 에서 ABE를 속성기반 접근제어의 기반으로 삼는 신뢰모델·함수·프로토콜을 규정하였다. 이 표준은 CP-ABE와 KP-ABE를 모두 포함하며, CP-WATERS-KEM·KP-GPSW-KEM·CP-FAME-KEM·KP-FAME-KEM 등 구체적 KEM(키 캡슐화) 스킴을 명시한다. 미국 NIST는 NIST IR 8450(2023 갱신판)에서 ABE의 개요와 고려사항을 정리했는데, 이는 규격이 아니라 도입을 위한 참고 보고서 성격이다. 2024~2025년 시점까지 ETSI·NIST의 새로운 ABE 규격 개정은 확인되지 않으며, 최신 현황은 ETSI TC CYBER 작업계획과 NIST CSRC를 직접 확인하는 것이 정확하다.

표준화가 중요한 까닭은 ABE의 가장 큰 실용 장벽이 기술이 아니라 상호운용성이기 때문이다. 접근구조 표현, 속성 명명 체계, 페어링 곡선 선택이 구현마다 다르면 서로 다른 벤더의 ABE 라이브러리로 암호화한 데이터를 교환할 수 없다. ETSI가 CP-WATERS-KEM 같은 구체적 스킴과 곡선·인코딩까지 못박은 것은 바로 이 파편화를 막아 "한 기관이 암호화하면 다른 기관이 열 수 있는" 생태계를 만들기 위함이다. 의료정보 교류, 전자정부 문서 유통처럼 조직 경계를 넘는 ABE 활용은 이 상호운용 표준의 성숙 없이는 성립하기 어렵다.

또 하나의 큰 흐름은 포스트 양자(PQC) ABE다. 현재 상용 ABE는 쌍선형 페어링에 기반해 양자컴퓨터의 쇼어 알고리즘에 취약하므로, [[post-quantum-crypto]]의 격자(lattice, LWE) 기반으로 ABE를 재구성하려는 연구가 활발하다. 다만 격자 기반 KP-ABE는 상당히 진전된 반면, LWE 가정 위의 CP-ABE 구성은 여전히 미해결에 가까운 난제로 평가되며, 표준화된 격자 기반 ABE는 아직 없다.

응용 측면에서는 전자의무기록(EHR) 공유, IoT 기기 간 세밀 접근제어, 명명데이터네트워킹(NDN) 콘텐츠 보호, 블록체인 기반 데이터 공유 등에서 ABE 적용 연구가 이어지고 있다. 특히 블록체인과의 결합이 주목받는데, 온체인에는 ABE 암호문의 해시·접근정책만 기록하고 본문은 오프체인(IPFS 등)에 두어, 탈중앙 환경에서 "기관 없는 세밀 접근제어"를 구현하려는 시도다. 이는 앞서 본 키 위탁·다기관 문제를 블록체인의 분산 신뢰로 완화하려는 접근이기도 하다. 종합하면 ABE의 실전 채택 폭은 폐지·성능·PQC라는 세 과제가 풀리는 정도, 그리고 ETSI·NIST 표준이 구체적 상호운용 프로파일로 성숙하는 속도에 따라 결정될 전망이다.

6. 고려사항 및 시사점

ABE는 "보호와 활용, 그리고 통제"를 암호 한 겹으로 묶으려는 야심찬 기술이지만, 그 야심만큼 성능·운영·신뢰의 비용을 동반한다. 기술사 관점에서 ABE 도입을 검토할 때는 이 비용을 직시하고 조직 맥락에 맞춰 선택적으로 적용하는 전략이 요구된다. 짚어야 할 전략적 고려사항은 다음과 같다.

• 적용 영역 선별(선별적 봉인 전략): ABE는 페어링 연산 비용과 폐지 난제 때문에 전사 데이터에 무차별 적용할 기술이 아니다. 유출 시 피해가 크고 다자 공유가 잦은 최상위 민감 데이터(의료·개인정보·영업비밀)에 선별 적용하고, 나머지는 RBAC·대칭키 봉투암호와 계층적으로 결합하는 것이 비용 대비 효과적이다.
• 폐지·수명주기 설계 선행: ABE 프로젝트의 성패는 암호화가 아니라 키·속성의 수명주기 관리에 달려 있다. 인사이동·퇴사·권한변경이 잦은 조직일수록 시간 기반 재키잉 주기, 속성 유효기간, 폐지 목록 관리 체계를 암호 선택보다 먼저 설계해야 한다. 폐지 비용을 과소평가하면 운영 단계에서 ABE가 짐이 된다.
• 신뢰 분산과 거버넌스(키 위탁 완화): 단일 AA의 전능성은 거버넌스·규제 리스크다. 다기관 ABE로 속성 발급 권한을 실제 조직 구조(인사부·보안팀·외부 인증기관)에 맞춰 분산하고, 에스크로 프리 구성으로 AA의 복호화 능력을 제한하는 것이 공공·의료 적용의 신뢰 확보에 유리하다.
• 성능·단말 제약의 현실 반영: IoT·모바일 등 자원 제약 단말은 다수의 페어링 복호화를 감당하기 어렵다. FAME류 고속 구성, 아웃소싱 복호화로 무거운 연산을 서버에 위임하되 결과 검증(verifiability) 을 결합해 서버 부정을 방지하는 하이브리드 설계가 필요하다.
• 암호 민첩성과 PQC 로드맵: 현행 페어링 기반 ABE는 장기적으로 양자 위협에 노출되므로, 알고리즘 교체가 쉬운 암호 민첩성(crypto-agility) 구조로 설계하고, 격자 기반 ABE·표준화 동향(ETSI·NIST)을 추적하는 전환 로드맵을 미리 마련해야 한다.
• PET 조합 아키텍처: ABE는 단독 해법이 아니라 [[homomorphic-encryption]](처리 중 보호)·[[differential-privacy]](통계 노출 제어)·[[multi-party-computation]](분산 연산)와 상보적이다. "접근은 ABE로 통제하고, 공유된 데이터의 분석은 동형암호·차분프라이버시로 보호"하는 PET 계층 조합이 데이터 활용·보호 동시 달성의 현실적 설계다.
• 감사성·책임추적성 확보: 암호로 집행하면 "누가 언제 무엇을 열람했는지"가 서버 로그에 남지 않을 수 있어, 접근제어의 강점이 역으로 감사·규제 대응의 약점이 된다. 복호화 이벤트를 변조 불가능하게 기록하는 로깅 체계나, 복호화 시 토큰 제시를 요구하는 보조 메커니즘을 결합해 책임추적성(accountability) 을 별도로 설계해야 개인정보보호법·전자금융감독규정 등 규제 요건을 충족할 수 있다.
• 속성 설계·온톨로지 거버넌스: ABE의 품질은 결국 "어떤 속성 체계를 세우느냐"에 좌우된다. 속성이 지나치게 세분화되면 키·정책 관리가 폭증하고, 지나치게 뭉뚱그리면 세밀제어의 이점이 사라진다. 조직 전반에 걸쳐 속성의 의미·값 범위·발급 책임을 정의하는 속성 온톨로지와 명명 표준을 먼저 수립하고 이를 지속 관리하는 거버넌스 체계가, 암호 알고리즘 선택 못지않게 ABE 프로젝트의 성패를 가른다.

참고자료

• ETSI TS 103 532 V1.2.1 (2021-05), CYBER; Attribute Based Encryption for Attribute Based Access Control: https://www.etsi.org/deliver/etsi_ts/103500_103599/103532/01.02.01_60/ts_103532v010201p.pdf
• NIST IR 8450-upd1 (2023), Overview and Considerations of Access Control Based on Attribute Encryption: https://nvlpubs.nist.gov/nistpubs/ir/2023/NIST.IR.8450-upd1.pdf
• A structured review of lattice-based attribute-based encryption for post-quantum security (Springer, 2026): https://link.springer.com/article/10.1007/s10791-026-09965-3

---

한 줄 요약: ABE는 신원이 아닌 "속성과 접근정책"으로 복호화를 통제하는 1:N 세밀접근제어 암호로, 서버를 신뢰하지 않고도 암호 자체에 접근제어를 녹여 넣지만, 폐지·다기관·키위탁·페어링 성능·포스트양자라는 난제를 어떻게 조율하느냐가 실전 채택의 관건이다.