히포

1. 포렌식 워터마킹의 필요성과 기술에 대한 이해

• DRM이 적용된 콘텐츠는 암호화된 상태로 배포되기 때문에, 동영상 파일을 다운로드하여 배포하더라도 사용 권한(DRM 라이선스)이 없는 사람은 해당 동영상을 재생하지 못하게 됨
• 하지만 DRM 기술만으로는 콘텐츠를 불법 유출로부터 완벽하게 보호할 수 없음
• 암호화된 DRM 콘텐츠도 권한이 있는 사용자의 기기에서 최종적으로 재생되기 위해서는 복호화 과정을 통해 원본 형태로 전환 → 재생 과정에서 여러 가지 기술적인 한계로 인해 콘텐츠가 유출될 가능성이 있음
• 하나 콘텐츠가 유출되는 경우에 해당 유출자가 누구인지 추적해서 더 이상의 콘텐츠 유출을 방지할 수 있는 기술 → '포렌식 워터마킹'
  
  
  

2. 포렌식 워터마킹란

• 포렌식 워터마킹(Forensic Watermarking)은 '디지털 워터마킹'이라는 기술의 한 분야
• '디지털 워터마킹'은 사진이나 동영상과 같은 각종 디지털 데이터에 저작권 정보 같은 비밀 정보를 삽입하여 관리하는 기술
• 콘텐츠 저작권자 또는 콘텐츠 서비스 제공자는 불법으로 유통되는 콘텐츠를 발견했을 때 워터마크를 검출해 유출 경로와 사용자를 추적
• 추적을 통해 해당 사용자에게 서비스를 중지하거나 법적인 조치를 취하는 등의 방법으로 불법 유출을 막을 수 있음

• 디지털 워터마킹과 포렌식 워터마킹의 차이
  1. 디지털 워터마킹 → 저작권자의 정보를 콘텐츠에 삽입해 저작권을 주장하는 용도로 사용
  2. 포렌식 워터마킹 → 콘텐츠 사용자의 정보를 삽입해 불법 유포를 추적할 수 있도록 해줌
     
     
     

3. 포렌식 워터마킹의 필요성

• 콘텐츠를 DRM으로 암호화해 보호한다고 해도 현실적으로 불법 유출을 100% 방지하는 것은 어려움
• 암호화된 상태로 안전하게 클라이언트(재생 기기)까지 콘텐츠를 전달한다고 해도 사용자가 콘텐츠를 이용(재생) 하기 위해서는 결국 복호화를 할 수밖에 없기에 유출하는 순간이 발생

• 최종 단계의 안전하지 않은 구간에 암호화되지 않은 상태의 콘텐츠가 노출되는 것을 보완하는 기술
  1. 하드웨어 기반 DRM
  2. Trusted Execution Environment (TEE)
  3. High-bandwidth Digital Conent Protection (HDCP)
     
     
     

4. 컨텐츠 유출

4.1. 유출 경로 1 - 캠코더를 이용한 화면 녹화

• 가장 전통적인 콘텐츠 유출 경로 중 하나
• 캠버전 영상으로 화면에 재생되는 영상을 별도의 캠코더나 스마트폰 카메라 등으로 촬영해 녹화본을 만들어 내는 것 → DRM 기술로는 콘텐츠 유출을 막을 수 없음
• 화면을 별도 기기로 촬영하는 것을 Digital-to-Analog (D2A) 또는 Analog-to-Digital (A2D) 변환이라고 하며, 워터마킹에 대한 다양한 공격 방식 중 하나로 사용됨
• 소형화, 고성능화되는 촬영 기기들로 인해 최근에는 Full HD를 넘어 4K/UHD 해상도로 원본과 거의 유사한 화질의 영상을 쉽게 촬영 가능
• 물리적으로 통제가 가능한 영화관보다 넷플릭스와 같이 가정에서 이용하는 OTT 서비스들에게 더 심각한 문제

4.2. 유출 경로 2 - 스크린 레코더를 통한 영상 캡처

• PC 웹 브라우저와 HTML5 플레이어를 통한 DRM 콘텐츠 재생 지원은 OTT 서비스의 가장 중요한 타겟 플랫폼 중 하나
• 일부 웹 브라우저의 경우에는 소프트웨어 기반의 DRM이 적용 → 각종 스크린 레코딩 툴을 이용하면 브라우저에서 재생되는 DRM 영상을 일반적인 MOV나 MP4 형태의 동영상 파일로 쉽게 저장이 가능
• 윈도우 OS의 IE11(윈 8.1 이상)과 에지(윈 10) 브라우저에는 PlayReady DRM이 적용 → OS와 하드웨어 레벨의 스크린 캡처 방지 기능이 적용되어 스크린 숏이나 동영상 캡처가 불가능
• 맥 OS의 경우에도 사파리 브라우저에서 재생되는 FairPlay Streaming DRM 콘텐츠 → 스크린 레코더를 이용한 영상 캡쳐가 방지
• 크롬과 파이어폭스 브라우저는 윈도우, 맥 OS, 리눅스 등 대부분의 지원 OS 지원 → 소프트웨어 레벨의 Widevine DRM이 적용되어 영상 캡처 방지 X
  

  

  
  
  
  

5. 포렌식 워터마킹 기술의 기본 원리

• 포렌식 워터마킹 기술에 필요한 요구 사항 중에서 가장 중요한 두 가지 요구 사항
  1. 비가시성
  2. 강인성

• 공격으로부터의 '강인성'을 위해 높은 강도의 워터마크를 적용하다 보면 '비가시성'이 떨어져 워터마크가 눈에 보이게 될 수 있음
• 강인성과 비가시성을 모두 만족시킬 수 있도록 적절한 수준으로 워터마크를 적용하는 것이 포렌식 워터마킹의 주요 기술

5.1. 비가시성(Imperceptibility)

• 원본 영상과 워터마크가 삽입된 영상의 차이를 시각적으로 인지할 수 없어야 함
• 눈에 보이는 '가시성(Visible)' 워터마킹의 경우, 원본 콘텐츠의 품질을 떨어뜨리고 영상 편집을 통해 쉽게 제거 가능하기 때문에 포렌식 워터마킹 솔루션으로 적합하지 않음
• 비가시성을 만족하기 위해 대부분의 포렌식 워터마킹 기술은 프레임 이미지의 눈에 보이지 않는 영역에 워터마크 정보를 삽입
• 비가시성을 만족하는 워터마킹 솔루션은 아래 이미지에서 비교 가능 → 왼쪽 이미지와 오른쪽 이미지의 차이를 확인 X
  

  

5.2. 강인성(Robustness)

• 재인코딩, 크롭, 필터링 등 다양한 공격에도 워터마크 정보가 손상되지 않아야 함
• 최종 사용자를 추적하기 위해서 워터마크 '고유성'이 요구됨
• 각 재생 세션(Session)마다 고유한 사용자 정보를 워터마크로 삽입하는 세션 기반 워터마킹 기술이 필요
• 세션 기반 워터마킹 기술은 세부적으로 클라이언트 기반과 서버 기반 기술로 나누어짐

• 5.2.1. 클라이언트 기반 (Client-side) 워터마킹
  • 콘텐츠를 재생하는 사용자 기기(클라이언트)에서 워터마크의 삽입이 수행되는 방식
  • 워터마킹 도입에 필요한 서버 백엔드의 수정이 최소화 가능
  • 특정 클라이언트만 지원 가능한 단점이 있음

• 5.2.2. 서버 기반 (Server-side) 워터마킹
  • 콘텐츠 서비스의 서버 측에서 워터마크 삽입이 처리되는 방식
  • 서버의 콘텐츠 워크플로우에 연동 작업이 필요
  • 클라이언트 플레이어의 제약이 없다는 장점이 있음
    
    
    

6. 포렌식 워터마킹 적용 분야

• 위동영상 콘텐츠의 불법 유출을 추적하기 위해, 다양한 방식의 포렌식 워터마킹 기술이 개발되어 여러 분야에서 사용

6.1. 스크리너(Pre-release)

• 영화 개봉 전에 리뷰를 위해 스튜디오 내부/외부 관계자들에게 파일이나 디스크 등의 형태로 사전에 배포되는 영화 콘텐츠를 말함
• 불법 유출 시 저작권자에게 큰 피해가 발생
• 배포되는 채널과 대상에 대한 워터마크 정보를 삽입해 유출을 방지

6.2. 디지털 시네마

• 디지털 필름 형태로 극장에서 상영되는 콘텐츠에 워터마킹을 적용해 불법 촬영에 의한 유출에 대응
• 주로 상영관과 상영 시간 등의 정보를 워터마크로 삽입
• 디지털 시네마 시스템과 연동이 필요

6.3. OTT VOD 서비스

• 온라인 영화 서비스(넷플릭스, 푹 등)의 프리미엄 콘텐츠에 포렌식 워터마킹을 적용
• 서비스의 최종 사용자 정보를 실시간으로 삽입해 불법 유출을 추적 가능

6.4. 라이브 서비스

• 월드컵 중계와 같은 실시간 이벤트를 서비스
• 불법적인 스트림 재전송을 감지해 즉각적으로 차단하기 위하여 포렌식 워터마킹이 사용

7. 멀티 DRM과 포렌식 워터마킹

• DRM이 '허가되지 않은 사용자의 콘텐츠 불법 사용을 방지'하는 기술
• 워터마킹은 '허가된 사용자에 의한 콘텐츠 불법 유출을 추적'하는 기술
• 'DRM'과 '워터마킹'은 상호 보완적인 역할로, 최신 할리우드 영화와 같은 높은 수준의 보안이 필요한 프리미엄 콘텐츠에는 필수적으로 함께 적용 필요
  

  

참고 URL : https://pallycon.tistory.com/entry/%EB%84%B7%ED%94%8C%EB%A6%AD%EC%8A%A4%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%BD%98%ED%85%90%EC%B8%A0%EB%A5%BC-%EB%B3%B4%ED%98%B8%ED%95%98%EB%8A%94%EA%B0%80-%EC%A0%9C2%EB%B6%80

1. 콘텐츠 보안과 멀티 DRM에 대한 이해

• 넷플릭스와 같은 유료 콘텐츠 사업자의 입장에서 가장 우려되는 부분은, 서비스하는 콘텐츠가 불법으로 유출되어 유료 가입자의 수가 줄거나 성장이 둔화되는 것
• 콘텐츠 불법 유출을 막기 위해서 넷플릭스를 비롯한 여러 OTT 서비스들은 'DRM'과 '워터마킹'이라는 기술을 이용해 콘텐츠를 보호

2. DRM이란?

• 디지털 권리 관리(Digital Rights Management, DRM)는 저작권자가 그들이 배포한 디지털 자료의 사용을 제어하고, 의도한 용도로만 사용하도록 제한하는 데 사용되는 모든 기술을 지칭하는 용어
• 주로 전자책, 음원, 동영상 등의 디지털 콘텐츠를 인증된 사용자가 인증된 기간 동안만 사용 가능하도록 통제 → 정당한 비용을 지불하지 않은 불법적인 사용을 방지하기 위해 사용

• DRM의 기능
  1. 콘텐츠의 암호화 및 복호화
  2. 암호 키 관리

• 원본 콘텐츠는 DRM 패키징이라는 과정을 거쳐 암호화된 상태로 사용자에게 전달 → 콘텐츠 암호화에 사용된 암호 키 정보가 없이는 해당 콘텐츠를 복호화해 재생할 수 없음
• 넷플릭스를 예로 들면, 넷플릭스 iOS/Android 앱에서는 '저장' 기능을 통해 일부 TV 프로그램 및 영화 콘텐츠를 모바일 기기에 다운로드하고 나중에 오프라인 상태에서도 시청할 수 있도록 지원
• 다운로드되는 영상 콘텐츠는 DRM이 적용되어 암호화 되어있기 때문에, 해당 파일들을 별도로 복사해 배포하더라도 권한이 없는 사용자가 일반적인 동영상 플레이어로 재생하는 것은 불가능
• 콘텐츠 사용 권한을 가진 사용자에게는 '암호 키'와 '사용 권한 정보'가 콘텐츠와 별도로 전달 → DRM 라이선스(암호 키 + 콘텐츠 사용 권한 정보)를 안전하게 전달하고 관리하는 것이 DRM 솔루션의 핵심 기술

3. DRM과 웹 브라우저 지원

• '화면이 있는 모든 기기에 넷플릭스 서비스를 제공한다'는 것이 넷플릭스의 비전 선언문
• 넷플릭스 서비스는 다양한 클라이언트 기기들을 지원
• PC와 노트북 사용자들을 위하여 웹 브라우저를 지원하는 것은 대부분의 온라인 동영상 콘텐츠 서비스에 매우 중요한 사항
• DRM이 적용된 비디오 콘텐츠를 웹 브라우저에서 재생하기 위해서는 다양한 기술이 필요 → 관련된 동영상 스트리밍, DRM 및 웹 표준 기술의 발전에 따라 여러 변화를 거쳐왔음

3.1. 과거 - 싱글 DRM과 플러그인

• 넷플릭스가 온라인 콘텐츠 서비스를 시작한 2000년대 초반부터 약 10여 년 간, 대부분의 콘텐츠 서비스들은 특정 DRM 업체가 제공하는 단일 DRM 솔루션을 적용해 콘텐츠를 보호
• 마이크로소프트 PlayReady, 구글 Widevine Classic, 어도비 Access, 인터트러스트 Marlin, 잉카엔트웍스 Netsync DRM 등의 다양한 DRM 솔루션들이 콘텐츠 서비스 업체의 선택에 따라 사용
• 다양한 DRM 솔루션을 싱글 DRM'솔루션이라고 하며, 모두 플러그인 방식 브라우저 지원이라는 공통의 문제점 발생

• ActiveX 컨트롤 설치 경고 메시지
  

  

• ActiveX 컨트롤 보안 경고는 대부분의 인터넷 사용자들에게 익숙할 정도로 많은 보안 솔루션에서 웹 콘텐츠와 애플리케이션 보안을 위해 사용
• 기존의 단일 방식 DRM 솔루션들도 웹 브라우저에서 재생되는 오디오/비디오 콘텐츠를 보호하기 위해 플래시와 같은 별도의 브라우저 플러그인을 사용해야 했음
• 각종 보안 이슈와 성능 등의 문제로 웹 브라우저들의 플러그인 지원이 중단되어 플러그인 방식의 DRM 솔루션은 시장에서 사라져 가고 있음

3.2. 현재 - 멀티 DRM, 플러그인으로부터의 해방

• HTML5 표준에는 플러그인 문제를 해결하기 위한 여러 규격들이 추가됨
• 인크립티드 미디어 익스텐션(Encrypted Media Extension, 이하 EME) 규격은 웹 브라우저 상에서 실행되는 HTML / Javascript 기반 웹 애플리케이션이 콘텐츠 보호 시스템(DRM)과 상호 작용할 수 있게 하는 API를 제공해 암호화된 오디오와 비디오를 재생할 수 있도록 함
• EME 규격과 미디어 소스 익스텐션(Media Source Extension, 이하 MSE) 규격을 통해 기존에는 별도의 플러그인으로 지원되던 DRM 콘텐츠의 재생이 웹 브라우저 자체적으로 지원

• 멀티 DRM이라는 용어가 사용되는 이유
  1. 크롬, 사파리, IE/엣지 등 각 브라우저마다 서로 다른 DRM을 기본 지원
  2. 마이크로소프트의 IE와 엣지 브라우저는 마이크로소프트에서 제공하는 PlayReady DRM을 지원
  3. 구글 크롬은 구글의 DRM인 Widevine Modular DRM을 지원
  4. 애플의 사파리는 FairPlay Streaming이라는 애플의 DRM을 지원
  5. 모질라 재단의 파이어폭스 브라우저는 크롬과 동일하게 Widevine Modular DRM을 지원

• 윈도우, 맥 OS 등 다양한 환경의 PC 사용자들에게 편리한 서비스를 제공하기 위해서는 기본적으로 PlayReady, Widevine Modular, FairPlay Streaming 이렇게 세 가지 서로 다른 DRM을 콘텐츠에 적용해야함
• 각 DRM에서 지원되는 스트리밍 방식에도 차이가 있음
  1. PlayReady와 Widevine → MPEG-DASH
  2. FairPlay DRM → HLS(HTTP Live Streaming)

• 브라우저 별 지원 DRM과 콘텐츠 형식
  

  

• 멀티 DRM 콘텐츠는 웹 브라우저뿐만 아니라 스마트폰, 태블릿, 스마트 TV 등 멀티 DRM을 지원하는 다양한 모바일 및 OTT 클라이언트 기기에서도 사용
• 멀티 DRM 적용으로 대부분의 사용자 환경을 지원할 수 있으며, 넷플릭스와 같이 멀티 DRM이 지원되지 않는 오래된 기기들까지 지원하기 원하는 경우에는 기존 방식의 DRM도 함께 사용

3.3. 미래 - CMAF을 통한 멀티 DRM의 콘텐츠 단일화

• 멀티 DRM을 통해 플러그인 없이 브라우저를 지원 가능 → 하나의 원본 콘텐츠를 두 가지 서로 다른 스트리밍 포맷으로 준비해야 하는 불편함 발생
• MPEG-CENC(Common Encryption) 규격에 따라 PlayReady와 Widevine DRM은 하나의 DASH 콘텐츠에 적용되지만, FairPlay DRM은 별도로 HLS 콘텐츠가 필요
• DASH/HLS 두 벌 콘텐츠가 필요한 문제점을 해결하기 위해, 단일 콘텐츠로 모든 브라우저와 플랫폼을 지원하는 CMAF(Common Media Application Format) 규격이 발표.
  

  

• CMAF 단일 콘텐츠가 현실화되기 위해서는 각 DRM과 플랫폼에서의 지원이 필요 → 마이크로소프트와 애플, 구글 등 관련 업체들의 협력에 의해 대부분의 문제점들이 해결
• 2019년 현재 시점에도 CMAF을 지원할 수 없는 클라이언트 기기들(구 버전 안드로이드 단말 등)이 시장에 존재하기 때문에, CMAF 단일 콘텐츠를 실제 서비스에 적용하기 위해서는 아직 더 많은 시간이 필요
• DRM 콘텐츠의 단일화 외에도 CMAF의 주요 장점으로는 'Chunked Transfer Encoding'이라는 기술을 통한 'Ultra Low Latency' 기능

• Low Latency
  1. 스포츠 중계와 같이 실시간으로 스트리밍 되는 라이브 콘텐츠에 가장 중요한 요소
  2. 최근 라이브 OTT 서비스 업계에서는 CMAF Low Latency 기술이 화두가 되고 있음
  3. CMAF을 통한 DRM 콘텐츠 단일화와 Ultra Low Latency 지원에 대한 내용은 별도의 글 → 참고 URL : https://pallycon.com/ko/blog/%EB%A9%80%ED%8B%B0-drm-%EC%BD%98%ED%85%90%EC%B8%A0-cmaf%EC%9C%BC%EB%A1%9C-%EB%8B%A8%EC%9D%BC%ED%99%94%ED%95%A0-%EC%88%98-%EC%9E%88%EC%9D%84%EA%B9%8C
     
     
     

4. 편리하지만 복잡한 멀티 DRM

• 플러그인 없이 브라우저를 지원할 수 있고 다양한 모바일과 OTT 기기들을 지원 가능한 멀티 DRM은 최종 사용자 입장에서 기존 방식의 DRM보다 훨씬 편리한 기술
• 멀티 DRM을 도입하는 콘텐츠 서비스 업체의 입장에서는 멀티 DRM은 여러 가지 서로 다른 DRM과 스트리밍 포맷을 적용해야 하는 복잡하고 어려운 기술
• 복잡한 멀티 DRM 기술을 쉽고 빠르게 적용하려면, 여러 DRM 기술을 통합해 단일화된 API를 제공하고 인코더/플레이어 등 각종 미디어 관련 솔루션들과 연동되어 있는 멀티 DRM 솔루션 업체를 이용하는 것이 좋음

참고 URL : https://pallycon.tistory.com/entry/%EB%84%B7%ED%94%8C%EB%A6%AD%EC%8A%A4%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%BD%98%ED%85%90%EC%B8%A0%EB%A5%BC-%EB%B3%B4%ED%98%B8%ED%95%98%EB%8A%94%EA%B0%80-%EC%A0%9C1%EB%B6%80

• DRM은 Digital Rights Management의 줄임말로 우리말로는 ‘디지털 저작권 관리’라고 해석
• 저작권자가 배포한 디지털 자료(문서, 파일 등)나 하드웨어의 사용 제한
• 특정 자료를 저작권자가 의도한 용도로만 사용하도록 제한하는데 사용되는 모든 기술(복사 방지, 기술보호 장치 등)
  

  

DRM이란

• 디지털 환경에서 콘텐츠를 만들어낸 지적 재산권 보호와 창작물을 사용하고자 하는 사용자의 의무와 권리를 보호하기 위한 기술
• 오프라인에서 내가 만든 제품이 있다고 하면 수공예품이건 공장에서 생산된 물건이건, 구매자의 손에 전달되기까지 유통 구조를 거치게 되고 더 나아가 판매한 제품에 대한 관리도 됨
• 온라인을 이용하게 될 때, 유사한 절차를 거치게 되는데, 만약 지적 재산권이 문제가 되지 않는다면 일반적인 온라인 마켓을 이용
• 창작한 콘텐츠에 대한 보호∙판매∙운영을 위해서는 DRM 솔류션 제품이 포함된 서비스를 사용
  

  

• 서비스를 제공하는 업체에서는 보통 원본 콘텐츠의 불법 유통 막기 위해 콘텐츠 보호 처리를 우선함
• 창작한 원본 콘텐츠가 예를 들어 도서, 책, 음반, 영화 필름과 같이 아날로그 콘텐츠인 경우, 디지털 콘텐츠로 변환하는 작업을 하게 되고, 다음으로 디지털 콘텐츠를 DRM 처리하여 변환하는 작업을 함 → 작업 과정을 패키징(packaging) 한다고 하며 패키징 하는 도구는 패키저(packager)
• 패키징 과정에서 불법 복사를 차단하기 위해 암호화와 불법 유통 시 복제 경로를 감지하기 위해 소유자의 정보를 삽입하는 워터마크 같은 기술이 콘텐츠에 적용되며, 저작권자가 설정한 콘텐츠 사용 규칙(라이선스 정보)이 라이선스 서버에 포함함
• 콘텐츠 사용 규칙은 콘텐츠 구매자에게만 해당하는 것이 아니라 콘텐츠 온라인 유통방법에 따라 서비스 제공자에 대한 유통 규칙이 포함될 수 있음

패키징은 시점을 기준으로 보통 두 가지 방법으로 구분

1. 사용자가 콘텐츠를 요청한 시점에 진행하는 방법(on-the-fly packaging)
   • 콘텐츠 크기가 비교적 작은 경우 예를 들어 문서파일이나 음원 파일 같은 경우에는 실시간 패키징

2. 사전에 패키징을 해 놓는 방법(pre-packaging)
   • 동영상이나 게임 설치 프로그램과 같이 콘텐츠 크기가 큰 경우에는 사전에 패키징

DRM 절차

1. 보호된 콘텐츠를 구매한 고객이 사용하기 위해서는 단말 기기에 DRM 복호화 모듈이 존재해야함
2. DRM 복호화 모듈의 역할은 서버로부터 사용자 인증과 라이선스 정보를 발급받아 콘텐츠를 복호화하는 것
3. 사용자가 콘텐츠를 사용하려는 시점에 DRM 콘텐츠 모듈은 인증서버를 통해 사용자 인증을 하게 되고 라이선스 서버를 통해 콘텐츠 사용 권한(지불 여부 확인) 여부 등을 판단하여 권한이 있는 경우 라이선스 정보를 제공
4. 라이선스 정보에는 콘텐츠를 복호화 하기 위한 키와 콘텐츠 사용 권리 중 제약 조건이 일반적으로 포함
5. 제약 조건의 주요 항목으로 권리 유효 횟수나 권리 유효기간 정보가 존재하는데, 사용자가 콘텐츠를 사용할 수 있는 횟수나 사용 만료 일자 정보를 의미
6. 정보를 받아 DRM 클라이언트 모듈은 복호화를 하게 되며 사용자는 콘텐츠를 사용할 수 있게 됨
7. 해당 콘텐츠를 웹 브라우저 상에서 볼 수 있는 환경이라면 웹 브라우저에서 지원하는 플러그인 형태로 DRM 클라이언트 모듈이 내장된 뷰어가 온라인 업체에서 제공될 것이며 그것을 받아 DRM 콘텐츠를 사용

DRM 흐름

1. 사용자가 문서를 작성
2. 문서를 암호화
3. 문서를 다른 사용자에게 배포
4. 열람 시 DRM Server로 부터 인증
5. 인증이 되면 문서 열람

DRM의 장점

1. 각 문서 단위로 권한제어
2. 문서 생성자가 적절한 권한을 부여하여 문서가 삭제 될때 까지 유지
3. 문서는 암호화 되어 권한을 가진 사용자만 접근 가능
4. 외부 유출 시에도 문서가 암호화되여 보호됨
5. 모든 로그가 DRM 서버에 기록이 됨

DRM의 단점

1. 암호화 해제 권한자에 의한 도면 유출을 차단할 방법이 없음
2. 어플리케이션(프로그램)에 종속적
3. 어플리케이션(프로그램) 버전이 변경 될때마다 추가 작업이 필요

ALPN

• ALPN은 Application Layer Protocol Negotiation의 약어
• ALPN(Application-Layer Protocol Interval)은 "Hello 메시지" 교환 내에 프로토콜 협상을 포함하는 TLS 확장
• ClientHello의 확장 기능으로, TLS handshake 이후에 application layer의 프로토콜과 버전을 결정하기 위한 기능
• ALPN → 프로토콜을 협상
  1. secure connection을 통해 처리
  2. 효율적인 접속
  3. 추가적인 round trips을 방지

• HTTP/2 프로토콜은 ALPN을 사용하여 웹사이트 로딩 시간을 줄이고 연결을 더 빠르게 암호화함
• 핸드셰이크 프로세스는 client에서 server까지 왕복 2회에 해당
• round trips이 많을수록 대기 시간은 길어지고 사용자는 서버로부터 정보를 받기 위해 더 오래 기다려야 함
• round trips의 수는 주로 client와 server(ex.. DNS, TCP, HTTP) 간의 통신을 시작하기 위한 핸드셰이크에서 발생
• round trips이 적은 상태에서 데이터를 전송하는 프로토콜을 개선할 수 있다면, 페이지 로딩 시간도 개선 가능

• ALPN은 HTTP/2에서는 HTTP의 버전을 합의하기 위해서 ALPN을 사용
• 먼저 client가 자신이 HTTP/1.1과 2를 지원한다는 사실을 ALPN으로 전송
• server가 ALPN과 HTTP/2를 지원한다면 ServerHello의 확장 필드에 h2를 적으면 handhshake 이후 HTTP/2로 통신이 시작
• ALPN을 지원하지 않으면, ServerHello에 ALPN 필드가 없으므로 HTTP/1.1로 통신
  
  
  

TLS handshake 동작 원리

• ALPN 확장을 사용할 경우의 이점을 완전히 이해하기 위해서는 먼저 TLS 핸드셰이크가 어떻게 작동하는 지 숙지 필요

• TLS handshake 단계 (TLS 포함)
  1. client와 server는 "Hello 메시지"를 교환하여 알고리즘에 합의하고 랜덤 값을 교환(exchange random value)하며 세션 재개(session resumption)를 확인
  2. 필요한 암호 파라미터(cryptographic parameters)의 교환을 통해 client와 server가 premaster secret를 허용
  3. master secret은 premaster secret에서 생성되고 임의의 값을 교환
  4. record layer에 security parameters를 제공
  5. client와 server는 peer가 동일한 security parameters를 계산했는지, 공격자가 조작하지 않고 handshake가 발생했는지 확인

• premaster secret
  • Client는 세션키를 생성하여 서버에게 전송
  • 암호화된 세션키를 premaster secret이라고 함

• master secret
  • 서버측에서 복호화할 때 사용
  • premaster secret을 통해 master secret가 생성
  • premaster secret을 사용하여 master secret를 복호화 → 데이터 추출 가능

ALPN의 동작 원리

1. ALPN client는 "TLS ClientHello 메시지"가 지원되는 application protocol 목록을 server로 전송 → "ClientHello 메시지" 안에 지원하는 목록을 가진 ProtocolNameList 필드를 추가
2. 목록을 수신한 server는 프로토콜을 선택하고 "ServerHello 메시지"로 프로토콜을 다시 전송 → 수신한 ProtocolNameList 필드를 살피고 "SeverHello 메시지"의 일부에 선택된 프로토콜을 나타내는 ProtocolName 필드를 반환
3. Server는 하나의 프로토콜 명을 응답하겠지만, 만약 Client가 요청한 목록에서 지원되는 것이 없다면 연결은 끊어지게 됨
4. 일단 TLS hadnshake가 완료되면 보안 연결이 수립되고 Client 와 Server는 어떤 응용프로그램 프로토콜을 사용할지 동의
5. 협상된 프로토콜을 통해 Client와 Sever는 바로 메시지를 교환 가능
6. aplication protocol negotiation은 TLS handshake 내에서 하나의 round trip에서 달성
7. 위 방법은 server가 각 application protocol에 다른 인증서를 연결할 수 있도록 함
8. support protocols 목록은 first message에서 server로 전송되어 필요한 왕복 여행의 양을 최소화

NPN vs ALPN (NPN과 ALPN의 비교)

1. NPN(client가 프로토콜 선택)

• Next Protocol Negotiation의 약어
• TLS Handshake 중에 효과적인 응용프로그램 프로토콜 협상을 위해서 구글에서 개발한 SPDY의 일부로 개발된 TLS 확장
• NPN은 ALPN의 전신이며 SPDY와 함께 널리 사용 (ALPN과 상당히 유사)
• NPN은 "ClientHello 메시지"에 지원되는 프로토콜 목록을 포함 X → ALPN과 차이
• NPN extension에서는 "ClientHello 메시지"에 프로토콜 목록이 포함되지만 일반적인 NPN은 client가 선택할 수 있는 프로토콜 목록을 다시 보내는 것은 server이다.

2. ALPN (server가 프로토콜 선택)

• NPN을 업그레이드 한 버전(client와 server의 프로토콜 목록 전송은 반대 과정)
• ClientHello 메시지는 server가 선택할 수 있도록 지원되는 프로토콜 목록을 포함
• ALPN은 "ClientHello 메시지"를 받은 이후 리소스 선택 프로세스(resource selection process)를 시작할 수 있어 역방향 프록시(reverse proxy)에도 유리
• ALPN이 다른 프로토콜 협상 표준과 더 유사
  
  
  

ALPN의 성장

• HTTP/2는 사용자 경험 향상(better user experience)과 로딩 시간 단축(faster load times)으로 인기가 높아짐
• ALPN 확장이 HTTP/2와 결합하여 제공됨으로 ALPN도 같이 성장
• 2016년 SPDY가 공식 폐지되면서 HTTP/2의 성장이 두드러짐
• 인상적인 속도 및 강화된 보안 기능으로 ALPN 발전
• 웹 사이트에서 HTTP/2 및 ALPN을 지원하는지 확인 : https://gf.dev/http2-test

ALPN 참고 자료 : https://www.ietf.org/proceedings/88/slides/slides-88-httpbis-1.pdf

1. 재시작

• 정상적인 절차를 사용하여 장치를 다시 시작
• reboot 명령어나 shutdown 명령어를 사용

2. 재설정

• 장치가 명령에 응답하지 않는 경우 전원 단추를 10초 동안 누름
• 전원이 꺼지면 디바이스가 다시 시작됨

3. 하드 리셋

• 위의 두 절차로 문제가 해결되지 않거나 일부 구성 요소가 응답하지 않는 경우 하드 리셋을 수행 필요
• 하드 리셋 진행 절차
  1. 서버 전원을 끕니다.
  2. 모든 전원 케이블, 네트워크 케이블에서 서버를 분리합니다.
  3. 전원 버튼을 10초 이상 계속 누릅니다.
  4. 전원 케이블 및 네트워크 케이블을 시스템에 다시 삽입합니다.
  5. 서버를 켜기 전에 iDRAC가 초기화될 때까지 약 2분 정도 기다립니다.
  6. 시스템의 전원을 켭니다. → 재시작
  7. 정상적인 절차를 사용하여 장치를 다시 시작합니다.

• PowerTop는 리눅스 시스템에서 전력사용을 모니터링 명령어
• 많은 서버를 운영하다보면 전원에 신경이 쓰이기에 전원 모니터링 필요

powertop 설치

• powertop 설치 방법

  $ yum install powertop

powertop 사용 방법

$ powertop

1. idle 상태를 확인 → 탭 간 이동은 tab을 이용, 종료는 q를 이용

2. Idle stats을 보면 C0로 되어 있는지 여부를 확인 가능

3. Frequency stats를 보면 CPU의 사용률 확인 가능

4. Device stats를 보면 Device들의 상태 확인 가능

5. c-state과 관련된 설정 확인 → Good / Bad에서 Bad가 나쁜 의미 아님(C-State와 관련 있는 설정을 의미)

참고 URL : http://egloos.zum.com/repository/v/5876237

C/G/S/P states

• intel_idle과 관련된 내용을 다루기에 앞서 P-States와 C-States에 대해서 간단히 정리
• Intel 아키텍처 환경에서 리눅스 커널과 CPU를 알아가다보면 P/S/G/C States에 대한 학습 필요

1. P-States

• P-States는 작업 부하에 따라서 CPU의 전압과 클럭주파수를 조절하는 정도를 정의 한 값
• 명령어 처리(Operation)상태를 기준으로 절전 및 성능 향상을 꾀하기 위한 기법
• 과거에는 SpeedStep이라는 기술로 소개 되었지만 정확히 같은 것은 아님
• P-States는 단순히 클럭주파수를 조절해서 에너지 절약을 위한 방안으로만 치부되었는데 CPU가 연산처리를 할 때의 상태를 반영
• 최근 사용되는 Intel CPU의 Turbo Boost 상태는 P-State 0(P0)를 의미

2. C-States

• C-States는 CPU 내부의 특정 부분이 활성화되거나 낮은 성능 상태로 실행될지를 반영하는 값
• CPU에서 사용중이 아닌 부분들을 비활성화하여 전원의 효율화를 높이기 위한 상태 값
• P-State와 다르게 C-State는 유휴(Idle)상태를 기준으로하여 평가
• C0는 활성화된 일반적인 상태를 의미하며, C0 상태에서 P0~Pn 상태로 나누어서 볼 수 있음
• Nehalem Microarchitecture(네할램)부터는 C6 상태가 추가되었는데 C6는 각종 작업들을 저장하고 이미 작동을 멈춘 CPU 코어에 공급되는 전원을 차단하는 상태
• Sandy Bridge Microarchitecture(샌디브리지)에서 C7이 추가되었고 이는 C6에서 추가로 L3캐시까지 비워버린(Flush) 상태를 의미

3. G-States

• Global States를 의미
• 사용자가 인지할 수 있는 상태를 반영
• G0는 동작상태 (전원 On)
• G1은 잠자기모드 상태
• G3는 전원 Off 상태

4. S-States

• Sleep States를 의미
• G1에서 세부적인 잠자기모드 상태를 나타냄

5. Processor Power States → 상태들을 알아보기 쉽게 도식화

intel_idle → Idle 상태를 관리

• C-States와 관련이 있는 모듈
• intel_idle이 사용되기 이전에는 C-States를 OS에서 관리하기 위해서 acpi_idle이란 모듈이 사용
• 기존 acpi_idle 모듈의 경우 C-State latency와 관련하여 정확도도 높지 않았고 기본적으로 BIOS 설정에 따라서 주어진 환경 내에서만 상태를 변경하는 정도로 효과 X
• intel_idle의 경우 BIOS 설정에 직접적으로 개입하여 C-State를 조절하는 모듈
• 서버시스템의 경우 빠른 응답속도를 목표로하기 때문에 소위 Performance 모드로 통칭되는 BIOS 설정상태를 유지하여 CPU가 잠들지 않도록 하는 설정하였지만, C-State를 커널이 개입하여 CPU 상태를 제어해 버리면 성능에 문제가 있을 수 있음
• 하드웨어에서 Performance이지만 커널에서 C6으로 C-State가 설정되어있으면 C6 상태에 있던 CPU가 C0 상태로 만들기 위한 시간(Wake-up time)이 소모되어 성능 저하 발생
• intel_idle 모듈 설정을 통해 BIOS 설정과 무관하게 커널의 C-State를 조절 필요

Idel 상태 관리 방법

• intel_idle.max_cstate 파라미터를 통해 C-State의 상태를 결정하거나 비활성화하여 apci_idle 사용가능
• 커널 부팅 파라미터에 intel_idle.max_cstate=0 값을 설정하면 apci_idle을 사용하여 하드웨어의 C-State로 부팅
• 커널파라미터의 경우 rebooting의 부담이 있기 때문에 기존에 운영하는 장비도 적용 할 수 있도록 tuned의 profile을 이용한 설정

1.커널 매개 변수로 intel_idle.max_cstate=0을 적용

• grub 파일을 쓰고 있다면, /etc/default/grub 파일에 intel_idle.max_cstate=0를 설정한 후 설정 적용(재부팅 가능)

• GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet" 항목에 intel_idle.max_cstate=0 추가

  # /etc/default/grub 파일 수정
  $ vi /etc/default/grub
  GRUB_TIMEOUT=5
  GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
  GRUB_DEFAULT=saved
  GRUB_DISABLE_SUBMENU=true
  GRUB_TERMINAL_OUTPUT="console"
  
  # 변경 전 내용 : GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet"
  # 아래 변경 후 내용
  GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rhgb quiet intel_idle.max_cstate=0"
  GRUB_DISABLE_RECOVERY="true"
  
  # /etc/default/grub 파일 적용
  $ grub2-mkconfig -o /boot/grub2/grub.cfg
  $ reboot

※ 참고

• 재부팅 후 intel_idle이 정상적으로 적용되었는지 확인 필요

  $ dmesg | grep -i intel_idle

2. tuned의 profile의 latency-performance의 profile을 이용한 설정

• tuned의 profile 중 latency-performance의 profile을 통해 커널파라미터의 경우 리부팅의 부담을 줄이고 C-state 변경 작업 적용
• 아래 결과를 통해 C7 상태까지 떨어지던 idle 상태가 C1이하로 내려가지 않는 것 확인

  $ tuned-adm profile latency-performance

• latency-performance 적용 전
  

  

• latency-performance 적용 후
  

  

3. E3/E5 계열(샌디브리지)의 CPU는 바로 적용이 되었으나 C6까지있는 네할렘 CPU에는 바로 적용 불가

• 실제 장비들을 샘플링하여 테스트 해 본 결과 tuned-adm을 설정하더라도 E3/E5 계열(샌디브리지)의 CPU는 바로 적용이 되었으나 C6까지있는 네할렘 CPU들은 적용 불가
• 네할렘 CPU에 C6은 계속 출력되는 것 확인
  

  

• /dev/cpu_dma_latency 장치(4바이트 값을 갖는 장치)에 직접 latency 값을 100으로 설정

  $ exec 3> /dev/cpu_dma_latency
  $ echo -ne '\0144\000\000\000' >&3

• 네할렘 CPU에 C3까지 출력되는 것 확인 → /dev/cpu_dma_latency 변경 확인
  

  

※ 아래 참조한 자료는 RHEL6 버전으로 RHEL7을 확인 필요

1. 참조 URL : https://lunatine.net/2015/01/06/rhel6-intel_idle-and-c-states/
2. 리눅스 ( Tuned 데몬을 이용한 OS 튜닝) 튜닝 참고 URL : http://justinsona.blogspot.com/2016/11/tuned-os.html

P-State란

• P-State는 시스템이 동작하는 동안, CPU의 클럭 주파수를 조절하여 어느 정도의 Performance로 CPU를 작동시킬 것인지 결정
• Intel의 X86 프로세서에서 P-State 기능을 SpeedStep이라는 이름으로 사용
• 리눅스는 P-State 기능을 "/sys/devices/system/cpu/cpu#/cpufreq/" 에 존재하는 파일을 이용하여 조절
• P-State는 시스템의 클럭수를 조절하여 동적으로 전체 시스템의 전력 소모를 조절
• CPU P-State는 Performace 상태로 정의된 voltage-frequency 제어 상태를 나타냄
• voltage-frequency 제어에서 회로를 구동하는 전압(voltage)과 클록(clock)은 작업 부하에 따라 증가하거나 감소함
• 운영 체제는 현재 작업 부하(workload)를 기반으로 특정 P-State를 요청
• 프로세서는 요청을 수락하거나 거부하고, 자체 상태를 기반으로 P-State를 설정 가능
• P-State는 프로세서가 지원하는 frequency와 수집 기간 동안 각 frequency에서 소요된 시간을 나타냄
• P-State에서는 SpeedStep, Speed Shift가 CPU의 클럭을 관리
  

  

P-State 핵심

• P-State가 CPU frequency를 떨어뜨려서 전력 소모를 줄이는 방법
• CPU 사용량이 적을때 CPU 코어의frequency를 떨어뜨려서 적은 voltage으로 CPU를 동작할 수 있게 하기 위해 사용
• CPU 코어 frequency와 voltage를 미리 정의 → 요청사항이 많을 때는 최대 frequency로 설정, 요청사항이 적은 때는 낮은 frequency로 동작
• Intel 계열 CPU에서는 SpeedStep이라는 이름을 사용
  
  
• Linux 상에서 cpufreq라는 인터페이스를 통해서 SpeedStep 기능 제어 → CPU frequency governor는 cpufreq로 frequency 결정
  1. cpufreq_performance → 전력은 많이 소비하지만 항상 최대의 성능으로 동작
  2. cpufreq_powersave → 최대한 전력을 아끼는 방법으로 동작
  3. cpufreq_ondemand → 주파수의 범위를 정해주고 부하 상황에 맞게 가변적으로 동작

P-State(active) 상태의 전원 관리

1. 스피트스텝(SpeedStep)

• 스피드 스텝 기술은 P-State를 제어하는 기술
• 인텔에서 개발한 기술
• CPU에 걸린 부하에 따라서 자동으로 클럭을 조절해주는 기술
• 배터리 소모량을 유연하게 조절하여 사용시간을 늘려주는 장점이 있지만, 클럭 조정시에 일시적으로 버벅임이 발생 가능
• SpeedStep의 주요 통제권은 OS가 가지고 있음
  
  
• 스피트스텝(SpeedStep) 작동원리
  1. 오피스 소프트웨어 이용하여 문서작업 등 비교적 부하가 낮게 걸리는 작업에서 CPU의 속도를 고의로 낮추어 작동
  2. HD급 동영상 재생 등 부하가 심하게 걸리는 작업에서는 CPU의 속도를 낮추지않는 방식으로 작동

2. 스피드 쉬프트(Speed Shift)

• 스카이레이크 마이크로 아키텍쳐를 가진 CPU 이후부터는 스피드 스텝을 하드웨어 단에 적용한 스피드 시프트 기술이 적용
• 베이스 클럭에서부터 터보 부스트 영역까지 확장된 기술
• 마이크로프로세서 안의 PCU(Power Control Unit)이라는 하드웨어가 밀리초 단위로 정해진 알고리즘에 따라 계산하면서 최적의 CPU 클럭과 전압으로 관리
• 스피드 쉬프트 기술을 이용하려면 OS에서 지원을 해야 사용 가능
• 스피드 시프트를 지원하지 않는 OS에서는 스피드 스텝으로 작동
• Speed Shift는 Speedstep과 달리 OS가 CPU 제어권을 대부분 PCU1에 넘겨 CPU의 클럭을 유동적으로 조절
• Speedstep과 비교하여 하드웨어적인 방식을 사용하기 때문에, CPU 클럭 제어 속도가 빨라졌고, 더욱 정밀한 클럭 계산이 가능해져 더 적은 에너지를 사용
• Speedstep이 20~30ms에 걸쳐 최대 클럭을 올릴 때, SpeedShift는 5~7ms만에 최대 클럭까지 도달 → 최대 50% 더 빠른 변속을 보여줌
• Speedstep과 Speed Shift는 동시에 적용 X

CPU frequency governor 이란

• CPU는 여러 주파수에서 동작이 가능하도록 설계되어 있으나, 리눅스 커널 대부분의 cpufreq 드라이버들은 CPU를 하나의 주파수로 설정
• CPU의 사용량이 많지 않으면 저속으로 많아지면 고속으로 동작할 필요가 있음
• 동적 주파수 확장을 제공하기 위해서 타겟 주파수를 드라이버에 알려줄 것이 필요가 있음
• CPU frequency governor는 CPUfreq policy내에서 무슨 주파수를 사용할 것인지 결정
• CPUfreq policy는 주파수 제한과 사용될 governor로 구성
• DB 서버에 CPUfreq policy가 활성화되어 있다면 CPU 주파수가 떨어질 때 쿼리 응답 속도가 갑자기 늘어난다던가 하는 이슈가 발생 가능
  
  

1. governor 종류

1. Performance→ CPU를 최고 주파수로 설정
2. Powersave→ CPU를 최저 주파수로 설정
3. OnDemand→ 현재 사용량에 따라 CPU frequnecy를 설정. CPU는 주파수를 빠르게 변경할 능력이 필요

2. 현재 설정된 governors 확인

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

3. 사용가능한 설정

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance powersave

4. governors 변경 → /sys/devices/system/cpu/ -> cpu[n] n 수만큼 다 변경해야함

# 먼저 CPU 개수 확인
$ cat /proc/cpuinfo | grep -i "^processor"
processor       : 0
processor       : 1
processor       : 2
processor       : 3
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15
processor       : 16
processor       : 17
processor       : 18
processor       : 19
processor       : 20
processor       : 21
processor       : 22
processor       : 23
processor       : 24
processor       : 25
processor       : 26
processor       : 27
processor       : 28
processor       : 29
processor       : 30
processor       : 31
processor       : 32
processor       : 33
processor       : 34
processor       : 35
processor       : 36
processor       : 37
processor       : 38
processor       : 39

$ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
$ echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
$ echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
#.... 중략....
$ echo performance > /sys/devices/system/cpu/cpu39/cpufreq/scaling_governor