of 252/252

네이티브 앱 VS 웹 Gap 분석서...웹 서비스 발전을 저해하는 한계를 맞이하게 되었다. 특히 비표준 기술은 보안, 결제, 인증, 멀티미디어, 게임

  • View
    0

  • Download
    0

Embed Size (px)

Text of 네이티브 앱 VS 웹 Gap 분석서...웹 서비스 발전을 저해하는 한계를 맞이하게...

  • Ⅰ.�개요

    1.�배경� ······································································································· � 3

    2.�목적� ······································································································· � 4

    3.�요약� ······································································································· � 4

    4.�적용환경� ································································································· � 5

    5.�활용대상� ································································································· � 5

    6.�문서의�한계� ··························································································· � 5

    Ⅱ.�웹�호환성

    1.�보안� ····································································································· � 10

    2.�인증� ····································································································· � 26

    3.�전자결제� ······························································································ � 47

    4.�멀티미디어� ··························································································· � 61

    5.�그래픽� ·································································································· � 72

    6.�전자문서� ······························································································ � 88

    7.�파일처리� ······························································································ � 96

    8.�게임� ····································································································· � 99

    9.�시스템�정보�확인�및� PC제어� ··························································· � 102

  • Ⅲ.�멀티�운영체제�및�브라우저�정책

    1.�멀티�운영체제�지원�정책� ·································································· � 111

    2.�브라우저�서비스�개발�정책� ······························································ � 113

    Ⅳ.�멀티�환경�지원�방안

    1.�멀티�브라우저�지원�방안� ·································································· � 119

    2.�멀티�스크린�지원�방안� ····································································· � 126

    Ⅴ.� NPAPI� 대체기술

    1.� NPAPI�대체기술�개요� ······································································· � 153

    2.� NPAPI�국내�사용�현황�및�분류� ······················································· � 156

    3.� NPAPI�대체�기술� ·············································································· � 158

    4.�주요�기능별�대체�기술�적용�방안� ···················································· � 166

    5.� NPAPI�전환�적용�사례� ····································································· � 171

    6.�비표준�대체기술,�실행파일�보안�이슈� ·············································· � 172

    Ⅵ.� HTML5

    1.� HTML5�표준�개요� ············································································ � 177

    2.� HTML5�신규�기능별�보안�이슈� ······················································· � 178

    3.� HTML5�브라우저�수용도� ·································································· � 192

    4.� HTML5�글로벌�동향�분석� ································································ � 208

  • Ⅶ.�부록

    1.�용어집� ······························································································· � 225

    2.�약어집� ······························································································· � 227

    3.�참고자료�및�인용� ·············································································· � 228

  • �제거�API�및�대체�기능� ·································································· � 22

    �주요�인증방법� ················································································ � 27

    �브라우저별�웹�암호�API� ································································ � 33

    �해킹�및�금융사기�주요�기법� ·························································· � 43

    �대체�인증�방식� ··············································································· � 44

    �국내�간편�결제�현황� ······································································ � 49

    �해외�간편�결제�현황� ······································································ � 50

    �주요�인증방법� ················································································ � 51

    �결제서비스�제공�주체별�분류� ························································ � 52

    �플랫폼�기반�분류� ········································································· � 53

    �해외�신용카드� ·············································································· � 55

    �결제단계별�플러그인�사용요소�및�개선방안� ······························· � 58

    � �요소�속성� ······································································ � 62

    � �요소의�재생�관련�속성,�자바스크립트�API� ·················· � 63

    �브라우저�제조사별�지원�코덱,� DRM� ·········································· � 64

    � �요소�속성� ······································································ � 66

    � ActiveX의�그래픽�기능을�대체할�수�있는�웹�기술� ···················· � 73

    � Canvas와� SVG의�비교� ································································ � 77

    �주요�애니메이션�및�전환�기능의�비교� ········································ � 78

    � Canvas�및� SVG�라이브러리� ······················································· � 83

    �주요�차트�라이브러리� ·································································· � 84

    �웹�에디터�종류� ············································································ � 89

    �주요�리포팅�솔루션� ····································································· � 90

  • �주요�플러그인�기반�그리드�컴포넌트� ··········································· 91

    �전자문서�보호�솔루션�제품들� ······················································ � 92

    �국내외�오픈�에디터의�특징� ························································· � 93

    �웹�표준�그리드�컴포넌트� ····························································· � 95

    �파일전송�ActiveX�사용현황� ························································ � 96

    � XMLHttpReqeust� readyState� ···················································· � 97

    �웹�표준� File� API�컴포넌트� ·························································· � 98

    � PC�원격제어�솔루션� ·································································· � 104

    �이용자�에이전트�문자열�토큰�설명� ··········································· � 106

    �윈도우� IE� Trident�토큰� ····························································· � 106

    �운영체제�연동�기술�현황� ····························································· � 112

    �브라우저�개발자�지원�정책�현황� ················································ � 113

    �브라우저별�확장�기능�지원�사이트� ············································· � 113

    � IE�고유�기술�및� Edge�대응�기술� ··············································· � 114

    � HTML5�주요�기능� ······································································· � 120

    �브라우저별�확장�기술�요약� ························································· � 124

    � NPAPI�대체�기술� ········································································· � 155

    �국내�NPAPI�사용�현황� ································································ � 156

    �국내�NPAPI�사용�현황�및�분야� ·················································· � 157

    �크롬�플러그인�실행�현황� ····························································· � 157

    �manifest�파일�구성�필드� ···························································· � 159

    �OS별�manifest�파일�위치� ·························································· � 159

  • �국내� 기능별�대체� 기술� ····························································· � 166

    �전자결제�대체�기술� ····································································· � 167

    �키보드�보안�대체�기술� ································································ � 167

    �공인인증서�대체�기술� ································································ � 168

    �대체�기술�구분� ·········································································· � 172

    � EXE�보안�취약점� ······································································· � 173

    � HTML5�신규�기능�요약� ······························································ � 178

    � CORS�관련�보안�위협� ································································· � 181

    �Web� Storage�설명� ····································································· � 182

    �OWASP� HTML5보안�위협�항목� ················································· � 190

    �브라우저별�웹표준�수용도� ··························································· � 198

  • [그림� 2-1]�바이오정보와�공인인증서를�연계한�간편인증�기술� ····················· � 12

    [그림� 2-2]� FIDO(Fast� IDentity� Online)인증기술�동작과정� ·························· � 12

    [그림� 2-3]�추출된�인증서로�별도�웹서버�운영(파밍)� ··································· � 13

    [그림� 2-4]�대칭키�알고리즘을�이용한�데이터�흐름에�대한�시퀀스�다이어그램·· � 20

    [그림� 2-5]� Cookie를�이용한�동작�명령�전달� ··············································· � 23

    [그림� 2-6]� CORS를�이용한�외부�애플리케이션과�정보�교환� ······················· � 24

    [그림� 2-7]�웹�표준�기반�공인인증서�서비스�모델�제시� ······························· � 31

    [그림� 2-8]�공인인증서�저장매체� ···································································· � 35

    [그림� 2-9]� IndexedDB에�공인인증서�저장�예� ·············································· � 36

    [그림� 2-10]�보안토큰과�브라우저�간�연동�모델� ··········································· � 38

    [그림� 2-11]�스마트인증�이용�절차�예시� ······················································· � 39

    [그림� 2-12]� Same-Origin�환경에서의�공인인증서�이용� ······························ � 40

    [그림� 2-13]�공인인증서�상호연동� ·································································· � 41

    [그림� 2-14]�Web�Messaging�메시지�통신�기능� ········································· � 42

    [그림� 2-15]� FIDO�인증�시나리오� ·································································· � 45

    [그림� 2-16]� TrustZone� Hardware� Architecture� ········································ � 46

    [그림� 2-17]�mPay�결제�프로세스� ································································· � 52

    [그림� 2-18]�페이핀�결제�프로세스� ································································ � 53

    [그림� 2-19]� Paypal�프로세스� ········································································ � 56

    [그림� 2-20]� video.js의�비디오�재생기� ·························································· � 65

    [그림� 2-21]� audio.js�재생기�화면� ································································ � 66

    [그림� 2-22]�WebRTC 브라우저 지원현황� ···················································· � 67

    [그림� 2-23]� YouTube� ··················································································· � 69

  • [그림� 2-24]�이퀄라이저�시각화� ····································································· � 70

    [그림� 2-25]� Canvas� 2D�샘플�코드�실행�결과� ············································· � 74

    [그림� 2-26]� SVG�예제�코드의�실행�결과(좌)와�결과물의�부분�확대(우)� ···· � 76

    [그림� 2-27]� Canvas�활용�게임(앵그리버드)� ················································· � 81

    [그림� 2-28]� SVG를�이용한�D3.js�차트� ························································ � 82

    [그림� 2-29]�레이아웃�발생의�예� ··································································· � 86

    [그림� 2-30]� Layouting으로�인한� Repaint�발생의�예� ·································· � 86

    [그림� 3-1]�운영체제�및�브라우저�정책�우선순위� ······································· � 111

    [그림� 3-2]� 2016년�이후� IE�지원계획� ························································· � 115

    [그림� 4-1]�웹�애플리케이션�개발을�위한�연관�표준�기술� ························· � 119

    [그림� 4-2]�크롬�지원�NPAPI�대체�플러그인�기술� ····································· � 125

    [그림� 4-3]� 태그�미적용/적용�사례� ·················································· � 128

    [그림� 4-4]�기기에�따른�Media� Query�적용�화면� ····································· � 129

    [그림� 4-5]�웹�폰트�그래픽� ·········································································· � 130

    [그림� 4-6]�고정폭/가변폭�콘텐츠�예시� ························································ � 131

    [그림� 4-7]� Bootstrap� Button� ····································································· � 133

    [그림� 4-8]� Bootstrap� Button� Group� ························································ � 134

    [그림� 4-9]� Ionic� Simulator� ········································································ � 140

    [그림� 4-10]� Ionic� Folder� Tree� ··································································· � 140

    [그림� 4-11]�코드변화가�적용된� Ionic� Simulator� ······································· � 141

    [그림� 4-12]� Alert�예시� ··············································································· � 146

    [그림� 4-13]� Custom�Alert�예시� ································································ � 148

  • [그림� 5-1]� asm.js�처리�플로우� ··································································· � 163

    [그림� 6-1]�브라우저�점유율� ········································································· � 177

  • Ⅰ.� 개요

  • - 3 -

    Ⅰ. 개 요

    1. 배경

    1989년 웹 초기 개발 목적은 웹을 탄생시킨 스위스 유럽원자핵공동연구소(CERN)의

    연구자들이 이기종의 운영체제(OS)와 개발 환경에서도 연구 자료를 쉽게 공유할 수 있

    도록 하는 것이었다. 그러나 현재의 웹 기술은 초고속 인터넷 인프라 발전에 힘입어 전

    자결제, 보안, 공공서비스, 전자문서, 멀티미디어, 소셜 네트워크 등 다양한 생활 서비스

    를 제공하는 기반 기술로 사용되고 있다. 특히 국내에서는 2000년 초반부터 초고속 인

    터넷 인프라 확산 정책이 진행되면서 단기간에 온라인 뱅킹, 오픈 마켓, 포털 등 다양한

    웹 서비스가 급속도로 보급되었다. 그러나 이러한 웹 기술 확산은 2000년 후반부터 특

    정 운영체제(OS, Operating System) 및 브라우저에 포함된 비표준 기술 때문에 오히려

    웹 서비스 발전을 저해하는 한계를 맞이하게 되었다.

    특히 비표준 기술은 보안, 결제, 인증, 멀티미디어, 게임 등에서 이용자 요구를 충족시키기

    위한 브라우저 개발사의 서로 다른 플러그인(plug-in) 기술 때문에 파편화(Fragmentation)된

    상태에서 빠르게 확산되었다.

    국내 웹 사이트 개발자들도 2000년 초에 Microsoft의 ActiveX, Firefox Netscape Plug-in

    API(이하 NPAPI) 등 비표준 기술들을 쉽게 사용함으로써 브라우저별 비호환성 때문에

    많은 어려움을 겪게 되었다. 2009년 아이폰 등 스마트 단말 시대를 맞이하여 애플의 사

    파리, 구글의 크롬 등 멀티 브라우저 및 모바일 웹 서비스 이용이 확산되면서 비표준

    기술 전환에 비용과 시간이 필요하게 되었다. 특히 최근 Windows 10에 기본 탑재된 Edge

    브라우저에서 비표준 기술인 ActiveX 사용을 전면 금지하거나, 2016년부터 구글 Chrome,

    Firefox 브라우저에서 NPAPI를 비활성화 하는 등 브라우저 자체에서 비표준 기술을 지

    원하지 않는 방향으로 정책이 변하고 있다.

    이러한 비표준 기술을 더 이상 적용할 수 없는 웹 서비스 환경에서 개발 인력과 구축

    비용을 절약하기 위해서는 한 번의 개발로 다양한 기기 및 브라우저에서 웹 서비스를

    제공할 수 있는 HTML5 표준 기술과 반응형 웹 기술에 대한 지속적인 기술 투자가 필요

    하며, 보안, 인증, 결제, 장치제어와 같이 운영체제와 연동하는 기술 적용 방식은 서버

    연동을 통한 인증과 보안에 문제가 생기지 않게 하거나 운영체제 개발 업체가 디지털

    서명을 인증하는 방식으로 개발 방법을 변경해야 한다.

  • - 4 -

    국내에서는 비표준 기술로 인해 발생한 인터넷 이용환경 문제를 개선하기 위해 2011년

    부터 인터넷 이용환경 개선 기술안내서 보급 및 웹 표준 전환 지원 컨설팅 사업을 벌이

    고 있다. 하지만 10여 년 동안 특정 브라우저와 비표준 기술에 의존해왔던 웹 서비스

    환경과 관련 법제도 변경 지연 등의 복합적인 요인으로 인해 비표준 기술 퇴출이 지연

    되고 있다.

    2. 목적

    본 안내서는 국내 웹 개발자 및 웹 사이트 운영자가 ActiveX, NPAPI와 같은 비표준

    기술을 개선하고자 할 때 참고할 수 있도록 주요 분야별 비표준 기술 사용 현황, 브라

    우저 개발사의 정책, 비표준 대체 기술의 기술별 특징, 구현 방법, 적용 시 고려사항 등

    에 대한 내용을 제공한다. 더불어 신규 웹 서비스 개발 시 발생 가능한 불편 사항을 개

    선할 수 있는 표준 웹 기술에 대한 구현 방안도 함께 제공하는 것을 목적으로 작성되었

    다.

    3. 요약

    본 안내서는 보안, 인증, 전자결제, 멀티미디어, 그래픽, 전자문서, 파일 처리, 게임, PC

    제어 등 웹 호환성 기술과 멀티 운영체제 및 브라우저 정책, NPAPI 대체기술, HTML5

    등 크게 5개 부문으로 구성되었다. 웹 호환성 부문의 경우 9개 기술로 분류하여, 각 기

    술에 대해 ActiveX, NPAPI 등 비표준 기술을 사용하지 않고 웹 호환성을 확보할 수 있

    는 방법 및 기술을 제시하고 있다. 멀티 운영체제 및 브라우저 정책은 브라우저 개발사

    의 전환가이드 적용 방법, 운영체제 기반의 응용 프로그램을 제공하는 방법, 브라우저

    개발사 권고 확장 기술의 적용 방법과 대안을 제시하고 있다.

    NPAPI 대체기술은 브라우저 개발사 권고에 따라 NPAPI와 같은 비표준 기술을 사용하

    지 않고 웹 표준 방식으로 상호호환성과 상호운용성을 확보하는 방법 및 기술을 제시하

    고 있다.

    끝으로 HTML5는 표준 규격과 웹 애플리케이션 규격, 구형 브라우저에 HTML5 지원

    방안, 보안 이슈, HTML5 브라우저 수용도, HTML5.1 글로벌 동향 분석에 대해 기술하고

    있다.

  • - 5 -

    4. 적용환경

    본 안내서에서 제시하는 방법은 대부분 윈도우와 맥 OS 환경에서 시험되었으며, 일부

    기술들은 모바일 기기에서도 시험되었다. 웹 서버는 윈도우 IIS와 리눅스 OS 기반의 아

    파치 웹 서버를 기준으로 하였으며, 클라이언트는 윈도우 및 맥 OS에서 동작하는 크롬,

    파이어폭스, 사파리 및 인터넷 익스플로러(IE) 등에서 시험되었다.

    HTML5 표준과 자바스크립트를 이용해서 구현된 기능은 HTML5를 지원하는 최신 브

    라우저에서만 동작하므로, 웹 개발자는 HTML5 표준 웹 기술을 이용하여 대체기술을 구

    현, 적용 할 경우 최신 브라우저의 버전과 http://html5test.com과 같은 표준 지원 확인

    사이트를 통하여 서비스를 제공 하고자 하는 브라우저의 HTML5 기능 지원 여부를 확인

    해야 한다. 참고로 2016년 10월 기준으로 PC용 크롬 53, 파이어폭스 48, 사파리 9.1, 인

    터넷 익스플로러 11 이상 버전에서 HTML5 표준 규격을 대부분 지원하고 있다.

    5. 활용대상

    본 안내서는 웹 개발자, NPAPI 개발자, 웹 사이트 운영자, 웹 솔루션 개발자를 대상으

    로 하였다. 본 안내서에서 개발자는 PM(Project Manager), 기획자, Front-End, Back-End,

    Desktop Application 개발자를 모두 포함하는 개념으로 정의하였다.

    6. 문서의 한계

    본 안내서에서 제시된 기술은 현장에서 사용되는 다양한 사례 중 일부만을 골라 제시

    된 것이다. 따라서 제시된 기술을 이용하여 상용 솔루션과 서비스를 구현할 경우 법제

    도, 조직 내부의 서비스 정책, 대상 고객의 이용환경 등을 고려하여 변경, 적용하여야

    한다.

  • II.� 웹� 호환성

  • - 9 -

    II. 웹 호환성

    이 부문에서는 웹 호환성 개선을 위해 국내에서 비표준 기반으로 사용되는 9개 주요

    기술 분야를 다룬다. 9개 기술 분야 중 전자결제 기술과 연관 있는 인증, 보안 기술은

    기존 공인인증서와 새로운 간편 결제 방식 사용에 대한 웹 호환성을 다루고 있다.

    보안 분야 중 키보드 보안과 같이 특정 기술이 필요한 솔루션의 경우 웹 표준 기술로

    대체할 수 있는 방법이 존재하지 않을 경우, 차선책으로 별도의 응용 프로그램을 제작하

    여 배포하거나, 브라우저와 응용 프로그램 간 서버 통신을 통해 서비스를 제공하는 방안

    을 대안으로 제시하고 있다. 이때 별도의 응용 프로그램을 구현하는 경우에도 특정 운영

    체제나 브라우저 개발 정책에 부합하고 비표준 기술에 종속되지 않도록 구현해야 한다.

    운영체제 및 브라우저 개발사는 상호 지원 방식에 따라 고유의 확장 방식을 제공하고

    있다. 운영체제와 브라우저를 결합된 형태로 제공하는 MS와 애플은 최근 자사 기술 정

    책과 로드맵에 따라 운영체제에 설치하는 응용 프로그램 기술과 웹 기술을 상호 독립적

    으로 운영하는 정책을 유지하고 있다. 반면 자사 운영체제 점유율이 미약한 구글과 모

    질라 재단의 경우 높은 브라우저 점유율을 기반으로 샌드박스 보안모델을 유지하면서

    자체 플러그인 기술로 웹과 운영체제 설치형 응용 프로그램이 유기적으로 연동할 수 있

    도록 기술 지원을 하고 있다. 다만 플러그인 기술 중 NPAPI의 경우 보안 및 안전성 문

    제로 인해 더 이상 브라우저가 지원하지 않는 점을 고려하여 브라우저별로 지원하는 다

    른 플러그인 기술을 확인해야 한다.

    크롬, 사파리, 파이어폭스, 오페라 등에서 전자결제 및 연관 기술로 활용되고 있는 NPAPI

    플러그인 기술의 경우 브라우저 개발사가 2016년을 시작으로 지속적으로 기술 지원을

    중단하였다. 따라서 멀티 브라우저에서 NPAPI를 확장 기술로 활용하고 있는 솔루션과

    서비스는 HTML5 웹 표준으로 전환하거나, 브라우저별로 지원하는 다른 플러그인(NaCl,

    pNaCl, ams.js, Native Messaging)으로 재개발할 수 있다. 또한 운영체제 설치형 응용 프

    로그램과 브라우저 간 서버 통신을 통해 대체할 수도 있다.

    웹 사이트에서 사용되고 있는 ActiveX, NPAPI와 같은 비표준 플러그인을 진단하기 위한

    방법은 자동화 도구를 활용한 방법과 특정 태그를 검색해서 페이지와 서비스 프로세스별로

    점검하는 방법이 있다. 현재 무료로 제공되는 자동화 점검 도구로는 www.koreahtml5.kr에

    서 제공하는“웹 표준 진단도구”를 활용할 수 있다.

  • - 10 -

    1. 개요

    HTML5 표준 환경에서 결제, 인증을 위해 가장 기본적으로 사용되는 보안을 위한 기술

    요소를 도출하고 각 기술 요구사항별 표준 대응 방안을 정리한다. 보안은 본인 확인을 위

    한 로그인 보안, 외부 불법적인 접근 또는 해킹 공격을 방지하기 위해 서비스 및 프로그램

    사용을 제한 통제하는 개인방화벽, 백신, 키보드 보안, 구간 암호화 등을 포괄한다. 또한 적

    격PG(결제대행사) 사업자 요구 보안 수준인 PCI-DSS(Payment Card Industry-Data Security

    Standard) 중 웹 서비스와 관련된 부분도 언급하였다.

    웹 서비스를 위한 정보보호 보안은 유무선 인터넷과 같은 네트워크를 통하여 전달되는

    정보의 위/변조, 유출, 무단침입, 서비스거부 등을 비롯한 각종 불법 행위로 부터 개인의

    컴퓨터와 인증, 결제 정보를 안전하게 보호하고, 물리적인 공간에서의 보안 침해사고 방

    지를 위해 서버, 이용자 PC(클라이언트)의 양방향 보안을 기본적으로 제공해야 하나 여기

    에서는 이용자 환경 보안을 좀 더 집중하여 내용을 구성하였다.

    2. 사용 현황

    2.1 로그인 보안

    로그인 보안을 위한 기술 요소를 도출하고 각 기술 요구사항별 표준 대응 방안을 정

    리한다. 기존 로그인 보안 방식은 대부분 공인인증서를 통한 로그인, 아이핀 등 공공기

    관에서 인증 심사를 하고 인증 전문업체가 솔루션을 제공하는 방식으로 인증의 안전성

    을 보장하여 제공하였으나, 최근 간편 결제가 활성화 되면서 휴대폰 번호, 카드 번호, O

    TP등 기존 지식기반(What you know)에서 인증 매체의 소지 편의성이 높은 기기를 활용

    한 소지 기반(What you have), 온라인 간편인증 FIDO(Fast IDentity Online)은 지문․홍채․얼굴인식 등 바이오 인식기술과 공개키 암호기술을 융합한 생체인증 본인 확인 기술이

    며 활성화되고 있다.

    1 보안

  • - 11 -

    가. 인증서 로그인 보안

    기존 공인인증서 로그인 시 주민등록번호 등 특정 값에 대하여 공인전자서명을 하고

    인증 서버로 전달, 인증 서버에서 공인인증서에 포함된 VID값으로 주민번호를 검증하여

    로그인을 허용하였으나, 최근 주민번호 수집금지 정책에 의해 주민번호로 로그인 인증

    하는 현행 방식을 더 이상 사용할 수 없게 되었기 때문에 공인인증서의 플러그인 의존

    도를 줄일 수 있는 웹 표준 방식의 공통기반 보안 기술 개발이나 보안토큰 기반 스마트

    폰 연계 방식(NFC)을 탑재하는 방식의 매체 보호 기술 개발 및 보급이 운용되고 있다.

    또한 공인인증서와 사설인증서를 병행 선택할 수 있는 법적 근거가 마련됨으로써 로

    그인 보안 기술을 웹 표준 기반으로 개선할 수 있는 방안이 마련되었으며, 간편 결제를

    통해 이를 활용한 웹 표준 기반 인증 보안을 상용화 하고 있는 추세이다.

    나. 아이핀/마이핀 보안

    아이핀은 인터넷상에서 주민번호를 대신하여 아이디와 패스워드를 이용하여 본인확인

    을 하는 수단으로 4개 본인확인기관 홈페이지나 네이버, 다음 등 i-PIN이 도입된 웹 사

    이트에서 발급신청이 가능하다. 아이핀 발급을 위해서는 본인확인 방식으로 휴대폰, 범

    용 공인인증서, 대면확인방식을 이용하여 발급이 가능하다.

    마이핀은 행정자치부에서 제공하는 본인확인 서비스로 기존 아이핀과 유사하나 주민

    번호를 대체하는 13자리 무작위 번호를 사용하여 본인 확인을 수행하고 있다.

    아이핀과 마이핀 모두 안정성을 강화하기 위하여, 아이핀과 마이핀 이용 시 ID/PW외

    에 추가인증을 하며 본인확인 방법으로 아이핀과 마이핀 ID/PW 입력 후, 2차 비밀번호

    또는 모바일 OTP입력을 하여야 한다.

    다. 온라인 간편인증 보안

    온라인 간편인증(FIDO) 기술은 지문․홍채․얼굴인식 등 바이오 인식기술과 공개키 암호기술을 융합해 비밀번호 입력 없이 본인인증 한 번만으로 결제가 가능한 기술로 스마트

    폰 등 다양한 모바일 단말기에서 생체인식 기술을 접목하여 비밀번호 입력의 불편함을

    제거하고 공인인증서를 스마트폰 USIM 등 하드웨어 플랫폼에 보관시키는 기술로 개발

    되었다.

  • - 12 -

    [그림 2-1] 바이오정보와 공인인증서를 연계한 간편인증 기술

    [그림 2-2] FIDO(Fast IDentity Online)인증기술 동작과정

    2.2 개인방화벽 및 백신

    개인방화벽과 백신은 개인이 직접 검증된 제품을 설치하여 사용하면 보안상의 요구를

    충족시킬 수 있다. 이용자 본인 책임의 안전한 금융 거래를 중시하고 있는 해외에서는

    이용자들에게 백신과 방화벽이 포함된 제품을 쓰도록 권고하고 있다. 그러나 사업자 책

    임의 비중이 더 큰 국내에서는 사업자가 개인방화벽과 백신을 제공하지 않아도 적절한

    제품이 정상 동작하고 있는지 확인할 필요가 있었으며, 현재는 ActiveX나 NPAPI, EXE

    방식으로 확인하고 있다.

  • - 13 -

    2.3 키보드 보안

    키보드 보안은 크게 2가지 역할을 한다. 첫 번째는 키보드로 입력되는 정보가 브라우

    저에 전달되기 전까지 또는 서버에 이르기까지 보호(키보드 보안 E2E 확장)를 해준다.

    두 번째는 키보드가 아닌 다른 방식(SW 방식)으로 입력된 정보가 브라우저에 전달되는

    것을 차단하는 것이다. 주로 보호하는 대상은 카드번호, 계좌 비밀번호, 이체 비밀번호,

    계정 패스워드, 인증서 비밀번호, 보안카드 값, OTP 값 등과 같이 외부로 노출되면 안

    되는 정보들이다.

    현재 키보드 보안을 위해서는 다양한 인터페이스로 연결되는 키보드로부터 입력되는

    정보를 보호하기 위한 드라이브가 필요하며, 이 드라이브를 메모리에 로딩하고 안전하

    게 통신을 하여 브라우저에 입력 값을 전달하기 위해서는 커널 모듈에 소프트웨어를 설

    치해야 한다. 지불결제 시 사용자 정보 입력 및 비밀번호 입력에 따른 보안 감시를 위

    해 최근에 EXE 방식이 도입되어 사용되고 있다.

    화면에서 입력한 정보를 직접 서버로 전달하는 방법이 있으나 서버에서 동기화를 맞

    추는 방법이 쉽지가 않아 현재 대부분의 솔루션은 별도 응용 프로그램과 주고 받아서

    수행하는 방식으로 구현하고 있다. 이를 위해서 대부분 PC에 로컬서버를 https로 운영

    중이며 그에 따른 인증서와 개인키가 노출되고 있어 일종의 악성코드 역할을 할 수 있

    는 가능성이 있다. 이는 사용 인증서를 로컬서버 인증서로 사용하고 있어서 발생하는

    문제로 해킹에 의해 인증서가 유출될 경우 파밍으로 이용될 수 있으며 인증서 발급기관

    에서 이 사실을 알아 인증서를 폐기할 경우 국내 서비스 대부분이 대책 없이 상당기간

    동안 서비스가 중단될 수 있는 가능성이 있다.

    [그림 2-3] 추출된 인증서로 별도 웹서버 운영(파밍)

  • - 14 -

    2.4 데이터 암호화

    데이터 암호화의 경우 이용자 브라우저와 같은 클라이언트나 웹서버 간의 통신, 그리

    고 서버와 서버 간의 통신 등 선로구간에 전자금융 정보나 개인정보 같이 민감한 데이

    터가 인터넷을 통해 전송되는 과정에서 데이터 노출을 방지하거나 데이터 접근에 대한

    경로를 추적하기 위한 방법으로써 데이터 자체를 암호화하여 저장해야 한다. 이래야만

    데이터가 유출될 시에도 내부 데이터를 사용하지 못하게 방지할 수 있기 때문이다. 특

    히 금융기관 또는 전자금융업자는 이용자와 서버 간의 전자금융거래내역 등 중요정보가

    유출되지 않도록 암호화를 통한 비밀성․무결성을 제공하여야 한다. 이를 위해 인터넷과 같은 공중망 환경에서는 송·수신되는 정보에 대한 보호대책이

    필요하다. 이러한 보호대책으로 SSL/TLS, VPN 등과 같은 다양한 통신 암호기술이 적용

    될 수 있다

    통신 데이터 암호화는 OSI 7 Layer중 Transport Layer와 Application Layer를 대상으로

    한다. Transport Layer에는 SSL/TLS Protocol이 적용되며 Application Layer에는 자바스크

    립트를 이용한 RSA Encryption/Decryption 또는 Symmetric Encryption/Decryption을 적용

    할 수 있다. 또한 Transport Layer 암호화와 Application Layer 암호화는 함께 공존 가능

    하나 Transport Layer 암호화(SSL/TLS)없이 Application Layer만의 통신 암호화를 구현하

    는 것은 매우 위험한 시도이므로 지양해야 한다.

    3. 대체 기술

    현재까지 보안 기술은 사용자 클라이언트에 보안 기술과 솔루션을 적용했다면 향후 보

    안 기술은 이상거래탐지 및 거래 단말 지정, PCI-DSS(Payment Card Industry-Data Security

    Standard) 기반의 고객 신용카드 정보를 위한 보안 표준 준수 등의 표준 보안 인증과

    FDS와 같은 서버 기반 기술, 고객 손해배상보장 등 비 기술적인 요소가 중요할 수 있

    다. 또한 웹 서비스를 위한 보안 서버와 HTTPS 구축 시 주요 취약점(암호 취약점, 프로

    토콜 취약점, 제품 취약점)에 대한 공격 패턴을 인지하고 대응해야 한다.

    로그인 보안, 개인방화벽, 키보드 보안, 데이터 암호화 등의 보안 대체 기술은 사용자

    의 이상 행위 및 외부의 불법적인 접근 또는 해킹 공격을 방지하기 위해 웹 표준 및 브

    라우저 확장 기술 기반 대체기술에 대한 안내이다.

  • - 15 -

    3.1 로그인 채널 보호

    가. SSL Configuration 정상 구성

    안전한 인증서 사용을 위해서는 SSL Configuration을 정밀하게 구성하는 것이 필요하

    며 공인 및 사설 인증서는 다수의 브라우저에 의해 신뢰할 수 있는 인증기관으로 등록

    된 인증기관으로부터 인증서를 발급받아 사용해야 한다. 또한 WebTrust 인증 등 제3자

    의 정기적인 보안 감사를 받는 인증기관의 인증서를 이용하는 것이 바람직하다.

    SSL 구성은 가능한 Protocol을 접속 클라이언트의 범위를 고려하여 정하되 특별한 경

    우가 아니라면 SSLv2는 사용하지 않도록 구성하고 암호화에 사용되는 암호화키는 최소

    한 128bit이상의 보안비도를 보장하는 Cipher Suites 목록을 지정하여 사용한다.

    나. Application Level Encryption 구성

    웹 표준 환경에서 자바스크립트를 이용하여 Application Level의 Encryption을 구현하

    여 사용하는 것을 권장하고 있으며 Application Level Encryption의 가용한 구성은 다음

    과 같다.

    - 공개키 암호 알고리즘 이용서버에서 공개키와 개인키 페어를 생성한 후 공개

    키를 클라이언트로 응답하고 클라이언트에서 데이터를 공개키로 암호화하여

    서버로 전송한다. 서버에서 개인키로 복호화하여 로그인 데이터를 확인한다.

    - 대칭키 암호 알고리즘 이용서버와 클라이언트 간 동일한 키를 공유한 경우

    클라이언트에서 데이터를 대칭키 암호화하여 서버 전송하고 서버에서 동일한

    대칭키로 복호화하여 데이터를 확인한다.

    다. Application Level Encryption 보안성 보장 조건

    - 강력한 보안구성을 SSL/TLS Transport Layer 상에서 운용한다.

    - Encryption/Decryption을 수행하는 자바스크립트에 대한 보호 대책을 적용한다.

  • - 16 -

    라. 2채널 관리를 통한 보안성을 보완한다.

    - APT, 키보드해킹, 메모리 위변조 등의 공격에 대비하기 위한 이중 교차 확인을

    통해 보안 취약점을 방어한다.

    - 채널 간 독립적 운영과 보호를 통해 보안사고 발생 시 대응 방안을 수립한다.

    3.2 자바스크립트 보호

    자바스크립트는 로그인 보안을 구성하는데 있어 실질적인 User Agent를 인지하고 서

    버에 인증을 처리하는 매우 중요한 역할을 수행한다. 이때 자바스크립트 보호 방안은

    매우 중요하며, 자바스크립트 보호 방안은 독립적으로 사용되거나 다른 보안 방식과 함

    께 사용될 수 있다.

    가. 자바스크립트 난독화

    - 자바스크립트로 중요한 비즈니스 로직 및 주요 정보를 서버에 전달할 경우 U

    ser Agent로 자바스크립트가 로드 되면서 해당 코드가 그대로 노출되어 해커

    입장에서 함수와 데이터, DB 테이블을 분석하게 되면 서비스 취약점이나 동

    적으로 자바스크립트 인젝션 공격을 통해 플러그인 설치 후 악성코드를 유포

    시키거나, 별도 쿼리를 만들어 내부 정보를 탈취할 수 있다. 이를 어렵게 하

    기 위해서 자바스크립트 난독화 기술을 적용한다.

    - Encryption/Decryption을 수행하는 자바스크립트에 대한 보호 대책을 적용한다.

    나. 자바스크립트 난독화 과정

    - 자바스크립트 Code내 모든 Symbol Name들을 난독화하기 위해 특별한 스트링으로 치환

    (예 :“hello”라는 심볼 네임은 다른 스트링으로 치환 “aadsfhdaskfd1asdfkfaskgfs”)

    - 자바스크립트 내의 주석(코멘트)을 모두 제거

    - 코드 내의 공백, 탭 또는 빈 줄을 모두 제거

    - 모든 코드를 한 줄로 연결

  • - 17 -

    다. 자바스크립트 동적 난독화

    일반 난독화 과정에서 자바스크립트 Code 내의 Symbol Name을 치환할 때 생성되는

    스트링을 세션에 기반한 난수로 생성한 코드로 치환한다. User Agent로 로딩되는 자바

    스크립트 코드는 각 세션별로 고유한 자바스크립트 코드를 가지게 된다.

    라. 자바스크립트에 대한 무결성 검증

    자바스크립트 코드에 대한 동적 난독화를 하였더라도 해커는 User Agent로 로딩 된

    자바스크립트 코드를 분석하고 변조할 수 있다. 따라서 서버에서 UA로 보낸 자바스크립

    트 코드가 변조 없이 실행되는 것을 보장하는 무결성 검증 방식을 추가로 개발해야 한

    다.

    마. 자바스크립트 동적 로딩

    트랜잭션 종류별 또는 단계별로 사용되는 자바스크립트 코드를 구분하여 필요한 자바

    스크립트 코드만을 UA로 로딩하여 사용하는 방식이 전체 비즈니스 로직의 노출을 방지

    하고 자바스크립트 코드를 경량화하여 보안성 및 속도 개선에 도움이 된다.

    바. 자바스크립트 Sandboxing

    자바스크립트 코드가 제3의 사이트에 혼합되어 사용되는 경우 제3자 자바스크립트 코

    드 동작에 의해 실제 자신의 자바스크립트 코드 실행에 영향을 미칠 수 있게 된다. 예

    를 들어 변수 사용이 중첩되어 변수 값을 탈취, 변조 등의 공격이 가능하며 이에 대한

    대책으로서 자바스크립트 코드의 Sandboxing 기법 사용을 권유한다. 대표적인 Sandboxing

    기법은 iFrame을 사용하는 것이지만 이 방법 이외에 Google Caja Project 등 다수의 Sandboxing

    기법이 있다.

  • - 18 -

    사. 자바스크립트 암호화

    - 자바스크립트 코드를 동적 난독화하거나 무결성 검증을 하더라도 코드 자체

    에 대한 노출을 원하지 않을 경우 서버에서 로딩되는 중간에 자바스크립트

    코드를 암호화할 수 있다. 자바스크립트 코드의 암호화는 Application Layer

    에서 Symmetric Encryption Algorithm을 사용할 수 있다. UA에서는 암호화된

    코드를 실제 실행하기 전 복호화하여 실행하고 폐기하는 것이 가능하다. 자

    바스크립트 코드를 복호화한 내용은 UA의 Sandbox Memory 내에서만 존재하

    며, 페이지 전환이나 DOM 개체의 삭제 둥의 행위로 메모리에서 코드 삭제가

    가능하다.

    - 자바스크립트를 사용하여 암호화를 구현할 경우는 실시간 공격을 배제한다면

    어떤 경우든 패스워드나 암호키에 보안성을 의존하게 된다. 결국 가능한 긴

    패스워드를 적용하여 사용될 수 있도록 할 필요가 있다. 물론 스크립트 상에

    비밀키가 노출되지 않아야 한다.

    3.3 보안 서버 및 페이지 암호화

    보안 서버란 인터넷상에서 사용자 PC와 웹 서버 사이에 송/수신되는 개인정보를 암호

    화하여 전송하는 서버를 의미한다. 보안 서버는 정보유출 방지, 위조사이트 방지, 웹 서

    비스 사이트 신뢰도를 보장하기 위해 인터넷에서 송/수신되는 개인정보(로그인 : ID/패스

    워드, 회원 가입 : 이름/전화번호, 인터넷 뱅킹 이용 : 계좌 번호/계좌 비밀번호)등을 SSL

    방식과 응용 프로그램 방식으로 암호화하는 방법이다.

    가. 보안 서버

    웹 서비스 구축 시 보안 서버 구축을 통해 HTML 소스코드가 https로 암호화되도록

    웹 페이지에 적용하고, 이를 통해 웹 서버와 브라우저 간 개인정보(ID, 패스워드, 주민등

    록번호, 전화번호, 이메일 등)를 암호화하여 송수신하는 기능을 제공할 수 있도록 구축

    한다. 검증된 보안 서버를 구축하기 위해서는 구축 시 보안 서버보급지원 정보 사이트

    (http://opa.or.kr/Business-secureserver_support.do)를 통해 신뢰할 수 있는 솔루션(업체) 및

    적용 범위, 적용 방법을 확인 후 자사 서비스에 반영한다. 보안서버 구축은 사용자 컴퓨

    터에 별도 보안 프로그램을 설치할 필요가 없는 SSL 인증서를 통한 암호화 전송 방식을

    사용하는 것이 바람직하며, 별도 응용 프로그램을 설치하는 방식을 지양해야 한다.

  • - 19 -

    - 또한 서버에서 RSA 키쌍을 생성 시 개인키의 키 사이즈는 2048bit이상이어야

    하고 서버에서 생성하는 개인키는 HSM 내에 보관하는 등 적절한 보호조치를

    취해야 한다.

    (생성된 키쌍을 세션에 저장해두고 세션 종료 시 자동 폐기되도록 조치하는

    방안도 고려가능)

    - 자바 스크립트로 제공되는 암호라이브러리는 많은 기능을 제공하지는 않는다. 따

    라서 여러 라이브러리들 중에서 사용하고자하는 알고리즘들을 선택하여 제공할

    필요가 있다. 일반적으로 많이 사용되는 것들은 다음과 같다.

    § WebCryptoAPI(http://www.w3.org/TR/WebCryptoAPI/) HTML5에서 지원하기 때문

    에 장기적으로 볼 때 가장 권고하는 방식이며 IE브라우저에서는 11버전에서

    부터 지원이 제대로 되고 있으며 Edge브라우저에서 완벽하게 지원이 된다. 지

    속적으로 추가 스펙이 만들어 지고 있어 가장 권고하는 방식이다.

    § Stanford JavaScript Crypto Library(http://bitwiseshiftleft.github.io/sjcl/) ECC중심

    으로 가볍고 빨라서 널리 사용된다. 그러나 지원 폭이 넓지 않기 때문에 용도와

    맞는지 확인 후 사용하기를 권고한다.

    § CryptoJS(http://code.google.com/p/crypto-js/) 제공되는 안전한 알고리즘도 많고

    사용하는 방법도 용이하다.

    § Jsbn(http://www-cs-students.stanford.edu/~tjw/jsbn/) 데스크탑과 모바일 브라우저

    에서 순수 자바 스크립트로 RSA와 ECC를 지원한다.

    § OpenPGP.js(https://github.com/openpgpjs/openpgpjs) 자바스크립트로 PGP를 지원

    하고 싶은 경우 선택할 수 있는 방법이다.

    § Jwcrypto(https://github.com/openpgpjs/openpgpjs) JSON환경에서 사용한다면 고

    려해볼 수 있는 라이브러리로 JSON Web Signature, JSON Web Tokens, JSON

    Web Certificates로 구현되어있다.

    - RSA 암복호화는 암호연산자원을 많이 소모하므로 대규모 데이터의 송수신에는

    적합하지 않아, 암복호화 속도를 고려할 경우 RSA 공개키 암호화보다는 빠른

    대칭키 암호 알고리즘을 이용하여 애플리케이션 데이터를 송수신하는 것을 권

    장한다.

  • - 20 -

    - 대칭키 알고리즘을 이용한 Data Flow에 대한 Sequence Diagram을 그려보면 아

    래와 같다.

    [그림 2-4] 대칭키 알고리즘을 이용한 데이터 흐름에 대한 시퀀스 다이어그램

    - 대칭키 생성은 Random Number 알고리즘을 이용하지만 통상 자바스크립트에

    존재하는 Math.random( )은 암호기술에서 사용될 수 있을만한 유의미한 수준

    의 함수가 아니다. 만일 브라우저에서 HTML5 WebCrypto getRandomValues( )

    함수처럼 True Random Number Generator를 지원한다면 해당 기능으로 대칭키

    를 생성하는 것을 권장한다. 브라우저에서 True Random Number 생성을 지원하

    지 않을 경우 마우스 이벤트, 디바이스 움직임 이벤트, W3C Web performance

    표준인 performance.now( ) 함수를 이용한 Micro Second를 조합하여 Entropy

    를 증가시킨 이후 해당 Entropy에서 Random Number를 생성하는 것을 권장

    한다.

  • - 21 -

    - SSL/TLS Transport Layer Encryption과 Application Layer Encryption을 함께

    사용 가능하지만 SSL/TLS Transport Layer Encryption 없이 Application Layer

    Encryption을 단독으로 사용하는 것은 매우 위험한 시도이므로 유의해야 한

    다. 또한 HSTS(HTTP Strict Transport Security)를 활성화하는 경우 Max Age

    를 가능한 긴 시간(31536000)으로 설정해야 한다. 서버에서 HSTS Header가

    활성화된 응답을 User Agent로 보내고 해당 User Agent가 이를 지원한다면

    이후 접속되는 모든 Connection은 HTTPS Protocol을 사용하도록 강제로 변경

    되므로 서비스 구현 시 유의한다. MS는 윈도우 10의 IE에 추가할 예정이었으

    나 최근 윈도우 7과 8.1상의 IE 11에 대하여 우선 지원하고 있으며, 구글 크

    롬은 2009년, Firefox는 2010년, Opera는 2012년부터 지원했다.

    나. 페이지 암호화

    보안 서버 설치 후 웹페이지(전체, 부분)에 암호화를 적용해야 하며, 이때 전체 페이지

    암호화의 경우 소스 수정 부분이 단순하지만 서버 부하 및 네트워크 지연 등 이용의 불

    편을 초래할 수 있어, 복잡도가 증가하지만 개인정보가 송수신되는 웹 페이지 부분에

    암호화를 적용한다.

    부분 암호화는 페이지별 암호화 방법과 프레임 암호화 방법으로 제공할 수 있다.

    - 페이지별 암호화는 현재 위치하고 있는 페이지에서 다른 페이지로 이동(링크)

    할 때 보안을 위해서 https 페이지로 이동하도록 개발한다.

    - 프레임 암호화는 (HTML5에서는 , 은 비추천 태그임)을

    활용하여 프레임에 삽입된 웹 페이지를 암호화된 페이지로 적용하여 개발한다.

    - 추가적인 웹 페이지 암호화 및 취약점 보안 개선 방안은“웹 서버 및 홈페이

    지 취약점 점검 가이드, 교육사이버안전센터”자료를 참고하여 웹 페이지 개

    발 보안 취약점을 개선한다.

    - 로그인 보안을 회피하기 위해서는 알려진 공격기법에 대한 최신 정보를 파악

    하고 대응해야 하며, 심각한 보안 취약성을 초래할 수 있을 경우 검증된 로

    그인 보안 상용 솔루션 도입을 통해 안전성을 높이는 방안이나, 검증된 외부

    서비스와 로그인 계정을 공유(OAuth)해서 이용자 로그인 정보 관리를 회피하

    는 방법을 강구할 수 있다.

  • - 22 -

    3.4 개인방화벽, 키보드보안 및 백신 대체

    개인방화벽, 키보드보안, 백신은 공인인증서 저장 위치와 인증서 접근에 따른 보안 문

    제를 해결하기 위한 요소로 대부분 설치와 이용 시 플러그인 문제가 발생하고 있다.

    개인방화벽은 이미 대부분의 윈도우 운영체제에서는 제공이 되어 무료로 사용하거나

    사용자가 직접 설치한 제품들에서 제공을 하고 있기 때문에 대체 가능하다. 따라서 이용

    자의 주도적인 선택에 의해서 활성화하거나 별도의 프로그램으로 설치를 안내해야 하

    며, 정상동작하고 있는지 점검하도록 안내하는 것이 필요하다. 주의할 것은 무료 백신

    중에는 방화벽 기능이 없는 경우가 있기 때문에 서비스 제공 시 이에 대한 안내 부분도

    고려하여야 한다.

    윈도우 10에서 커널(Kernel) 구조가 변경되었으며, 커널을 접근하는 소프트웨어는 x64

    기반의 컴퓨터 시스템을 로딩하기 앞서 Windows Driver Kit(WDK)을 통해 디지털 서명

    을 해야 한다. 이에 따라 부트 시작 드라이버는 커널 모드 코드 서명을 위한 디지털 인증

    서를 발행하는 상업적 인증기관(CA)으로부터 소프트웨어 간행 인증서(Software Publishing

    Certificate; SPC)를 획득해야 한다. 또한 IE 10 이하에서 제공하던 API가 IE 11에서 제거

    됨에 따라 아래의 대체기능을 이용하여 서비스하도록 기존 소스를 변경할 필요가 있다.

    제거 API 및 대체 기능

    제거된 API 기능 대체 기능

    attachEvent addEventListener

    window.execScript eval

    window,doScroll window.scrollLeft, window.scrollTop

    document.all document.getElementByld

    document.fileSize, img.fileSize XMLHttpRequest를 사용

    script.onreadystatechange script.onload

    script.readyState script.onload

    dodument.selection window.getSelection

    document.createStyleSheet document.createElement

    style.styleSheet style.sheet

    window.createPopup div, iframe을 높은 zIndex값과 함께 사용

    이진 동작 표준 기반(예, canvas, SVG, CSS3 애니메이션)

    레거시 데이터 바이딩 프레임워크의 바인딩 사용(예, WinJS)

  • - 23 -

    또 하나의 문제는 브라우저가 구동되는 시점을 인지하고 개인방화벽과 백신이 금융

    거래나 결제가 진행되는 동안 브라우저의 이벤트와 메모리를 계속 감시할 필요가 있다.

    이를 위해 운영체제 내 탑재된 애플리케이션과 브라우저 사이의 안전한 정보 교환이 가

    능해야 하며 개인방화벽, 백신 개발업체가 애플리케이션과 브라우저가 통신 할 수 있는

    방안을 만들어야 한다.

    [그림 2-5] Cookie를 이용한 동작 명령 전달

    현재 검토되고 있는 방식은 Cookie, Web Socket 등을 사용하는 방식부터 다양한 시도

    를 하고 있으나 양방향 통신에 여러 제약이 존재하고 브라우저의 Extension을 사용할

    경우 각 브라우저 별로 지원 가능한 플러그인 기술을 확인해서 개발 되어야 하는 단점

    이 있다.

    Cookie를 사용할 경우 브라우저 외부에서 실행 중인 개인방화벽이나 백신에 명령을

    전달하기는 용이하나 역으로 개인방화벽이나 백신에서 그 상태를 브라우저에 전달하는

    것은 용이하지 않다. 즉 외부에서 그 값을 바꿔도 브라우저를 재시작하기 전에는 그 값

    이 반영되지 않는다. Local Storage를 이용하는 경우도 Cookie와 동일한 방식으로 동작

    한다.

  • - 24 -

    Web Socket이나 CORS(Cross-Origin Resource Sharing)를 활용하여 외부 애플리케이션

    과 통신을 수행할 수 있다. 그러나 https로 서버와 연결을 맺은 상태에서는 IE의 경우

    https로만 통신이 가능하다. Web Socket의 경우에도 동일한 현상이 발생한다. https 통

    신을 위해서는 로컬에 인증서와 개인키 설정이 필요한데 이는 localhost에 대하여 브라

    우저에서 허용하는 인증서 발급도 불가하지만 사설로 만들어서 운영한다고 하여도 공격

    자에게 이용당할 수 있기 때문에 추가적인 보안 조치 방안이 필요하다.

    [그림 2-6] CORS를 이용한 외부 애플리케이션과 정보 교환

    기존 동작방식에 집착하지 않고 서버를 상호작용에 포함시켜 브라우저 키보드보안 및

    백신 서버 브라우저와 같은 흐름으로 정보를 주고받을 수도 있으나 기존 방식을 사용하

    고 있지 않을 경우 서버의 동작 방식을 바꾸는 위험이 뒤따른다. 또는 시큐어 브라우저

    와 같은 개념의 방식을 통하여 보안제품이 브라우저를 보호 감시하면서 브라우저를 악성

    코드의 공격이나 해킹으로부터 보호하는 방법을 사용할 수도 있으나 이 경우에도 시큐어

    브라우저가 서버에 정상 동작하고 있음을 알릴 방안이 필요하다.

  • - 25 -

    따라서 개인방화벽, 키보드보안과 백신의 경우 유의할 사항은 브라우저와 운영체제에

    상주하고 있는 애플리케이션 사이의 상태 정보 전달을 위한 통신을 위해서는 항상 제품

    이 실행되고 있는 상태이어야 하며, 이용자가 금융이나 결제, 공공 업무를 수행하는 시점

    에 대해 인지하고 실행하고 있어야 한다. 결국 전자서명에서 처럼 URI Scheme Callback

    방식을 통하여 실행시킬 수는 있으나 이용자가 직접 키보드 보안 및 백신 프로그램을

    실행해야 한다. 이외에도 Windows에서만 가능하지만 장애인접근성을 해결하기 위해 도입

    된 기술인데 이를 응용하여 정보전달 수단인 Microsoft Active Accessibility (MSAA) Control

    API를 이용한 회피 방법, Localhost loopback 방식(웹 서버 탑재)을 이용한 모니터링 방

    식, 브라우저의 메모리 이벤트 모니터링을 확인하기 위해 다른 프로세스에 침투하는

    Dll injection 방식 등을 사용할 수 있으나 해커가 레지스트리를 조작하거나 Hooking 함

    수를 교체하는 위험성이 있어 운영체제 개발 정책에 따라 언제든지 차단될 위험성이 있

    다.

    결국 개인방화벽, 키보드보안 및 백신은 현재 상태 정보를 알기 어려우며 지속적인

    상태 점검이 필요하기 때문에 서버 연동까지 고려하지 않는 한 문제 해결이 쉽지 않다.

    향후 보안을 위해서는 운영체제 애플리케이션 형태로 상시 실행하는 것이 바람직하다.

    추가로 키보드 보안의 대체 기술로 각광 받고 있는 가상 키보드의 경우 RCS를 통한

    해킹 가능성이 있으므로 화면저장(캡처) 방지기술을 탑재해서 배포하는 것도 고려의 대

    상으로 포함시켜야 할 것이다.

  • - 26 -

    1. 개요

    인증 기술은 클라이언트와 서버가 인터넷과 같이 통신으로만 연결된 상태에서 서명을

    통해 본인의 행위를 신뢰할 수 있도록 지원하는 기술로 이를 통하여 불법 이용자의 접

    근을 막고 거래를 허용할 수 있게 된다.

    인증 기술은 크게 세가지로 지식기반, 소지(토큰)기반, 생체기반으로 나눌 수 있으며, 공

    인인증서의 경우 지식기반의 대표적인 예이며, 소지기반의 경우 OTP(One Time Password)

    토큰이 대표적인 예이다. 최근 사용되고 있는 생체 기반의 경우 생체학적 특징 중 가장

    일반적인 지문인식 및 홍채인증이 사용되고 있다.

    국내 인증(전자서명)의 경우 대부분 지식기반인 공인인증서를 통한 본인확인을 하고 있

    으며 서버 방식을 통한 전자서명과 본인 인증 기술 보급은 미약한 상황이다. 해외의 경우

    HTTPS를 통해 서버 인증서에 해당 도메인이나 주소를 포함하여 접속 서버와 인증서를 상

    호 인증하는 방식을 대부분 사용하고 있다. 인터넷 상거래나 인터넷 트랜잭션 보호에서

    인증 기술은 안전한 키 분배를 위한 수단으로 사용되기도 하고 서버에 접근하는 이용자를

    명확하게 식별하기 위한 수단으로 사용하고 있다.

    최근 기존 공인인증서를 보완하는 기술로 서버에서 자동으로 지시하는 랜덤 값 문자(이

    미지)를 자신의 ID 또는 패스워드와 혼합해 입력한 후 서버로 전달하면 서버는 지시 문자

    를 제외한 입력 값을 자동 추출한 후 로그인을 수행하는 방법이나, OTP를 내장한 스마트

    카드, 보안 토큰, FIDO(Fast Identity Online) 국제 표준 기술 규격을 준수하는 생체 인증을

    통한 이중보완 방법으로 사용하는 2채널 인증 방식을 통하여 본인확인 및 전자서명을 강

    화하는 방법 등이 상용화되고 있다.

    2 인증

  • - 27 -

    2. 사용 현황

    현재 인터넷 환경에서의 인증 부분은 본인 확인보다 결제 등에서 사용되는 전자서명

    의 부인방지 부분에 비중을 많이 활용되고 있어 공인인증서 대체기술에서 부인방지 기

    능이 반드시 제공될 것을 요구하고 있다. 최근 공인인증서 의무 사용이 폐지됨에 따라

    전자상거래 시 신용·체크카드로 전자결제를 하는 경우 공인인증서 대체 사용이 자율화

    되었으나, 나머지 전자금융거래(보안 가군, 예: 인터넷뱅킹)에는 공인인증서 또는 공인인

    증서 수준의 안전성을 갖춘 인증 방법을 대체할 수 있는 기술 요구되고 있다. 현재 예

    외가 되는 경우는 1회, 1일 거래한도를 적정선으로 낮춘 경우만 가능하며, 대부분의 모

    바일 간편 결제가 이에 해당한다.

    현재까지 공인전자서명을 구현하고 인증서 운영 및 보호를 위해서는 ActiveX, NPAPI

    이외에도 별도의 확장 기술(URI Scheme, 로컬 웹 서버, dll injection)을 필요로 한다. 이

    는 브라우저 개발사가 국내의 특수한 인증서 운영 환경을 고려한 추가 기능을 제공하지

    않기 때문이며. 결국 운영체제 개발사 및 브라우저 개발사의 기술 정책 변경에 의해 별

    도의 확장 기술이 퇴출되면 현재 ActiveX 나 NPAPI 퇴출 문제와 같이 또 다른 기술 방

    식을 개발해야 하는 악순환이 반복될 수 있다.

    결국 은행(정보 변경, 이체 실행), 카드사의 전자상거래에서 거래 사실 확인 및 부인

    방지를 위해 사용하고 있는 공인인증서를 대체하거나 일체 설치 파일이나 실행 파일 없

    이 웹 표준 방식으로 변경하면서, 2-Factor 인증과 같은 두 단계의 인증 체계를 통해 부

    정 사용을 보완하는 방식을 선택하고 현재 사용하고 있는 비표준 확장 기술을 퇴출할

    때이다.

    최근 브라우저 플러그인을 사용하지 않고 웹 표준 구현기술만을 활용하는 공인인증서

    발급 및 이용 기술이 개발되고 있으며, 몇몇 은행에서는 본인 확인을 위한 스마트 OTP

    카드 등의 대체 기술을 보급하고 있다.

    주요 인증방법

    인증 방법 설명

    공인인증서여러 가지 인증방법 중 하나로서 사전에 발급받은 공인인증서와 비밀번호를

    통해 신용카드 결제 인증

    구 인증신용카드 번호, 카드 비밀번호 앞 2자리와 생년월일(2014년 8월 이전에는 주민

    번호 뒤 7자리 또는 사업자번호)로 카드소유자 확인을 하는 인증방법

  • - 28 -

    2.1 본인 확인

    본인 확인은 기본적으로 대면 인증을 통한 최초 인증과 이후 비대면 인증을 통한 사

    후 인증으로 구분할 수 있다. 현재 본인 확인 방식은 공인인증서를 통한 방식이 일반적

    으로 사용되고 있으며, 지난 10여년 동안 인증서를 운영하는 기술이 특정 운영체제 및

    브라우저 의존성이 강한 비표준 기술로 운용되었으며, 로그인, 아이핀 등 공공기관에서

    인증 심사를 하고 인증 전문업체가 솔루션을 제공하는 방식으로 인증의 안전성을 보장

    하였다.

    최근 간편 결제가 활성화 되면서 휴대폰 번호, 카드 번호, OTP 등 기존 지식기반(What

    you know)에서 인증 매체의 소지 편의성이 높은 기기를 활용한 ARS 확인과 같은 소지

    기반(What you have), 생체 인식 기반(Biometrics)으로 본인확인 수단이나 보안 방법을

    보호하기 위한 기술이 활성화되고 있다.

    또한 하나 이상의 본인 확인 인증 방식을 결합하여 2단계로 인증을 진행하는 2-Factor

    방식을 사용하여 SMS 인증 후 OTP 인증을 추가로 수행하는 방법, 지문인식 후 OTP 인

    증을 추가로 수행하는 방법, PKI 토큰을 이용한 비밀번호 입력 후 OTP 인증을 수행하는

    방법으로 본인 확인을 강화하는 추세이다.

    안심클릭 인증

    카드 발행사와 카드 소유자간에 상호 알고 있는 정보를 토대로 안심클릭 인증

    정보를 생성하고 이용자가 등록된 올바른 인증 정보를 제공할 수 있는지 여부로

    본인확인

    ISP 인증

    카드 발행사와 카드 소유자간에 상호 알고 있는 정보를 토대로 ISP 인증 정보

    를 생성하고 이용자가 등록된 올바른 ISP 인증 정보에 근거하여 생성한 전자

    서명(Digital Signature)을 서버에서 검증하여 본인확인

    AA 인증

    랜덤한 승인금액을 생성하여 이용자가 승인금액이 얼마였는지 알아낼 수 있는

    지 여부로 본인 확인 또는 승인금액을 고정하고 가맹점 명칭에 포함된 랜덤코

    드를 이용자가 알아낼 수 있는지 여부로 본인확인

    ARS 인증

    카드사에서 이용자가 사전에 지정한 전화번호로 전화를 걸어 본인 확인을 하

    는 형태로, ARS시스템에 의해 자동으로 이용자에게 전화가 걸리며, ARS 멘트

    로 거래 내역 사실이 이용자에게 안내되면 확인 후, 최종적으로 고객이 승인

  • - 29 -

    2.2 공인인증서(전자서명)

    공인인증서의 경우 웹브라우저의 확장기능을 배제하고 W3C가 제정한 웹 표준 구현

    기술만을 활용하여 브라우저의 로컬저장소(localStorage)에 공인인증서를 저장하고 전자

    서명을 받는 방식(Agentless)으로 서비스를 제공할 수 있다. 웹 표준 기반 공인인증서 서

    비스는 운영체제, 웹브라우저, 단말기에 상관없이 웹을 통해 공인인증서를 발급받아 이

    용하고자 하는 모든 서비스에 적용하고. 공인인증서 이용방식을 웹 표준으로 구현함으

    로써 사용자가 별도의 공인인증서 소프트웨어를 설치하지 않아, 이용불편과 접근성이

    해소될 것으로 보인다. 특히 데스크탑, 스마트폰, 스마트 TV 등 웹 브라우징이 가능한

    모든 환경에서 공인인증서를 이용할 수 있는 장점이 있으나 공인인증서 운용(발급, 저

    장, 이용, 갱신, 폐기) 및 보호를 위한 확장 기술 기반의 Agent 미설치로 인해 로컬저장

    소를 이용함에 따른 보안성 저하 문제와 웹 표준 구현기술인 자바스크립트를 이용함으

    로 발생할 수 있는 웹 취약점 관련한 문제에 대해서는 적절한 보완이 필요하여 현재 이

    를 보완하는 방식으로 2-Factor 인증 방식인 OTP 보안 매체를 활용한 추가적인 본인

    확인 절차를 수행하는 서비스를 제공하고 있다.

    3. 대체 기술

    사용자 본인 확인을 위한 대체 기술은 대부분 공인인증서를 통한 로그인 인증과 금융

    거래의 무결성 확인 및 거래사실 부인방지를 위한 전자서명 용도로 사용되고 있어“웹

    표준 기반의 공인인증서”운용 방식에 대한 기술과 공인인증서를 사용하지 않고 본인확

    인 및 부인방지를 하며 무결성을 보장하는“대체 인증 수단”,“인증 관련 기술적 보완

    방식”등 세가지 방향으로 구분할 수 있다.

    본인 확인 및 전자서명을 위한 웹 표준 기반의 공인인증서 운용 방식에 대한 기술은 보

    안 위협에 대처하기 위한 자바스크립트 샌드박스, 웹 콘텐츠 보호(W3C CSP), 자바스크립

    트 동적로딩, 자바스크립트 난독화 및 암호화, 자바스크립트 무결성 검사, WebCryptoAPI

    등의 보호 수단을 적용해서 개발해야 한다.

    공인인증서를 사용하지 않고 본인 확인 및 부인방지를 하는 기술은 이용자가 가지고

    있는 것으로 식별하는 OTP, 보안카드 등이 있고 이용자가 알고 있는 것으로 식별하는

    패스워드, 사이트 키(Site Key) 등이 있다. 이와 별도로 이용자 신체의 특징이 되는 지문,

    홍채, 정맥 등이 있고 이용자 행동의 특징인 입력 리듬, 필체 등이 있다. 그러나 이중에

  • - 30 -

    충분한 안전성을 확보 하면서 인터넷상에서 사용할 수 있는 기술로 받아들여지는 것은

    공인인증서, OTP 정도를 일반적으로 사용하고 있다. 이러한 공인인증서를 사용하지 않

    는 본인 확인 및 부인방지 기술은 초기 구매 비용이나 개인정보보호 문제로 보급 확산

    과 사용에 제약이 있는 상황이다.

    인증 관련 기술적 보완 방안은 일반 운영체제나 브라우저에 인증서를 사전 탑재하는

    방식과 FIDO(Fast IDentity Online)와 같은 생체인증, 기존 인증방식의 연동 방식, 이상거

    래탐지시스템(FDS)을 활용되고 있다.

    거래사실 부인방지는 이용자에 대한 신뢰를 바탕으로 이용자가 본질적으로 거래한 사

    실이 없다면 이용자의 손해를 보전하는 방향으로 발전해야 하며 거래사실이 있지만 이

    용자가 부인하는 경우 정황증거(로그 등)나 제3자를 활용하여 이용자를 설득할 수 있도

    록 해야 한다.

    마지막으로 인증방식은 거래 리스크나 신용 정보에 따라 각기 다른 방식을 채택하고,

    이용자가 선호하는 인증 방식을 선택할 수 있는 다양성을 확보하는 것이 바람직하며,

    인증이 필요한 영역별로 분할된 인증 방식을 적용하는 것도 고려해야 한다.

    3.1 웹 표준 기반 공인인증서

    가. 브라우저에 인증서 탑재

    브라우저 로컬저장소에 공인인증서를 저장하고 웹 서비스를 통해 전자서명을 지원하

    는 방식으로, 기존의 공인인증서를 하드디스크나 별도의 메모리 장치(USB)에 저장하던

    방식에서 사용하던 비표준 플러그인 설치가 없는 장점이 있는 반면, 본인 확인 및 거래

    안전성 보강을 위한 OTP와 같은 추가 인증 방식이 필요하다. 이 방식을 사용할 경우 기

    본적으로 로컬저장소는 웹 암호 API 적용 등을 고려하여 웹 스토리지를 사용 시 인증서

    보호 기술을 적용하는 것을 우선적으로 권고하고 있다.

  • - 31 -

    [그림 2-7] 웹 표준 기반 공인인증서 서비스 모델 제시

    웹 표준 기반 공인인증서 서비스를 위해서는 공인인증기관은 공인인증서 발급을 별도

    통신채널과 Protocol을 사용하지 않고 브라우저만으로 발급할 수 있도록 시스템을 갖추

    고, 전자거래, 전자민원 등 이용기관은 발급‧저장된 공인인증서를 이용하여 전자서명문을 생성할 수 있도록 웹 페이지 내에 기능을 구현하여야 한다. 또한 공인인증기관 및

    보안업체는 안전한 공인인증서 저장을 위해 다양한 저장매체를 도입하고 웹 표준과 연

    동하여야 한다.

    나. 공인인증서 발급

    기존에 브라우저 플러그인을 통해 발급하던 공인인증서를 웹 표준 구현기술 만으로

    발급하기 위해서는 공인인증기관의 발급시스템과 Protocol의 변경, 클라이언트인 브라우

    저에서의 발급기능 구현이 필요하다. 공인인증기관은 HTTP를 통해 발급할 수 있도록

    발급방식을 변경하고, 브라우저에서는 전자서명키 쌍과 인증서 요청양식의 생성, 응답을

    처리하여 저장하는 기능 등을 구현하여야 한다. 또한 공인인증기관은 브라우저만으로

    공인인증서를 발급하기 위해서는 발급시스템에 대한 변경이 필요하다. 공인인증서의 발

    급과 관리는 발급시스템과 클라이언트 간의 요청과 응답을 위한 메시지를 통해 이루어

    지며, 이 때 메시지는 특정 Protocol이 아닌 HTTP(또는 HTTPS)를 통해 전송되어야 한다.

  • - 32 -

    기존 공인인증서 발급시스템을 활용하고 웹 표준을 적용할 수 있는 방법은‘HTTP Transfer

    for the Certificate Management Protocol’를 준용하는 것이다. [RFC6712] 공인인증서 발

    급‧관리와 관련한 모든 요청과 응답은 HTTP를 통해 PKIMessage로 처리 가능하며 기존 발급시스템의 활용 또한 가능하다.

    RFC6712를 준용하기 위해서, CMP(Certificate Management Protocol) 메시지는 반드시

    HTTP를 사용하여야 하며 HTTP/1.0, HTTP/1.1을 모두 지원해야 한다. 또한 GET이 아닌

    POST방식만을 사용하여 메시지를 전송하여야 한다. PKIMessage를 전송하는 동안 HTTP

    헤더의 콘텐츠 타입으로 application/pkixcmp로 설정하여야 한다.

    DER 인코딩 ITU.X690.1994된 PKI Message RFC4210는 HTTP POST 요청을 본문에 담

    아 보내며 HTTP 요청이 성공하면 서버는 HTTP 응답에 CMP 응답메시지를 담아 보낸

    다. 이 경우 HTTP 응답코드는 200이어야 하며 요청 성공과 관련한 다른 응답코드(2XX)

    는 이 경우 사용해선 안 된다.

    더 상세한 표준내용은 [RFC6712], [RFC4210] 등의 표준문서를 참고해야 하며, 관련 표

    준 규격 이외에도 기존 발급 프로세스에 대한 변경도 고려해야 한다.

    다. WebCryptography API 활용

    웹 암호(WebCryptography) API의 경우 현재 표준규격(W3C Proposed Recommendation)

    제정이 되었고, 일부 최신 브라우저에는 관련 기능이 탑재되어 있어 사용이 가능하며 htt

    p://caniuse.com/#feat=cryptography에서 브라우저 버전별 웹 암호 API 지원 정보를 얻을

    수 있다.

  • - 33 -

    브라우저별 웹 암호 API

    아래와 같이 WebCryptography API를 사용하여 전자서명키 쌍을 생성할 수 있다.

    [예시 : 웹 암호 API 사용 전자서명 키쌍 생성 ]

    브라우저 명 웹 암호 API 소개 페이지

    인터넷 익스플로러(Edge, IE 11) http://msdn.microsoft.com/ko-kr/library/ie/dn265046(v=vs.85).aspx

    크롬http://www.chromestatus.com/features/5030265697075200 https://code.google.com/p/chromium/issues/detail?id=245025

    파이어폭스https://developer.mozilla.org/ko/docs/Web/API/Window/cryptohttps://bugzilla.mozilla.org/show_bug.cgi?id=865789

    사파리(웹킷)http://blog.engelke.com/tag/webcrypto/https://bugs.webkit.org/show_bug.cgi?id=122679http://nightly.webkit.org/

    var subtle = window.crypto.subtle;

    var publicKey;

    var privateKey;

    var extractable = false;

    var algorithmKeyGen = {

    name: "RSASSA-PKCS1-v1_5",

    modulusLength: 2048,

    publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // Equivalent to 65537

    hash: {

    name: "SHA-256",

    }

    };

    subtle.generateKey(algorithmKeyGen , extractable, ['sign']).then( function(e) {

    publicKey = new crypto.key(e.publicKey);

    privateKey = new crypto.key(e.privateKey);

    resultCallback ( {

    publicKey: publicKey,

    privateKey: privateKey

    } );

    }, function(e) {

    resultCallback(new crypto.error(e));

    } );

  • - 34 -

    생성된 키쌍을 이용하여 전자서명을 수행하는 것은 다음과 같다.

    var subtle = window.crypto.subtle;

    var algorithmSign = {

    name: "RSASSA-PKCS1-v1_5"

    };

    plain = crypto.util.stringToArraybuffer(input);

    Subtle.sign(algorithmSign, privkey, plain.buffer).then(

    function(e) {

    resultCallback(crypto.util.arrayBufferToString(e));

    }, function(e) {

    resultCallback(new cryoto.error(e));

    }

    );

    웹 암호 API이외에도 암호화 통신 알고리즘을 안전하게 사용하기 위해서는 보안 결함이

    발견된 SHA(Secure Hash Algorithm)-1 해싱 알고리즘은 더 이상 사용하지 말아야 한다.

    2016년 1월 1일 이후 브라우저 개발사(Microsoft, Google, Mozilla)는 SHA-1 서명 인증서에

    대한 신뢰중단이 되었으며, 기존 SHA-1로 서명 발급된 모든 SSL, CA 인증서는 신뢰를 보장

    할 수 없다. 따라서 2016년 1월 1일 이전에 기존 SHA-1을 SHA-2 알고리즘 기반 인증서로

    반드시 재발급 및 갱신해야 한다.

    (SHA-2 전환일정 : https://www.ucert.co.kr/ssl/sha2-timeline.html)

    웹 암호 API에 관한 보다 상세한 내용은 현재 표준화가 진행 중인 W3C Web Cryptography

    API(http://www.w3.org/TR/WebCryptoAPI/)를 참고할 수 있다.

    라. 공인인증서 저장

    비표준 플러그인 기반의 기존 공인인증서 저장 환경은 주로 하드디스크와 이동식 디스

    크 내의 /NPKI/ 디렉토리에 저장되었다. 하지만 웹 표준 환경에서는 별도 플러그인을 사용

    하지 못하고 웹 표준 File API의 경우 디렉토리 접근이 자유롭지 않기 때문에 기존 방식으

    로 저장하는 것은 어렵다. 웹 표준 방식으로 공인인증서를 발급 받은 후 저장할 수 있는

    저장매체는 브라우저 내의 웹 저장소, 보안토큰, 소프트토큰, 스마트인증 등이 있다.

  • - 35 -

    [그림 2-8] 공인인증서 저장매체

    - 웹 스토리지(WebStorage)

    공개키 HTML5의 웹 스토리지(Web Storage)는 HTML5 표준으로 웹 사이트의 데이

    터를 브라우저에 저장할 수 있는 새로운 자료구조로서 기존 쿠키(Cookie)의 단

    점을 개선하기 위해 개발되었다. 현재 웹 스토리지는 모든 브라우저에서 지원

    가능하며 저장된 데이터는 서버로 전송되지 않는다. 웹 스토리지는 클라이언트

    디바이스에 직접 저장되고 네트워크로 전송되지 않기 때문에 네트워크 레벨에

    서는 �