지금은 뭐라고 불러야 할지 잘 모르겠어서 헤드라인에서 하이브리드 이름으로 언급했습니다. 마이크로 소프트 오피스 365.
(Microsoft의 워드 프로세싱, 스프레드시트, 프레젠테이션 및 협업 앱의 집합명사인 "Office"라는 이름은 죽이다 다음 달 또는 두 달에 걸쳐 단순히 "Microsoft 365"가 됩니다.)
사람들이 계속해서 개별 앱 이름(워드, 뛰어나다, 파워 포인트 및 친구) 및 스위트룸의 이름 Office 소프트웨어를 처음 접하는 사람들은 아마도 다음과 같이 알게 될 것입니다. 365, 유비쿼터스 Microsoft 접두어를 삭제한 후.
아시다시피 Office 독립 실행형 앱(실제로 로컬에 설치하여 작업을 위해 온라인에 접속할 필요가 없는 앱)에는 저장된 문서를 암호화하는 자체 옵션이 포함되어 있습니다.
이것은 나중에 실수로나 의도적으로 파일을 수신하지 않아야 할 사람과 공유하는 경우에 대비하여 보안 계층을 추가해야 합니다. 이는 이메일을 통해 첨부 파일을 공유할 때 실수로 실수하기 쉽습니다.
받는 사람에게 파일 잠금을 해제하는 데 필요한 암호를 제공하지 않는 한, 그에게는 양배추가 너무 많이 파쇄되어 있습니다.
물론 이메일 본문에 비밀번호를 포함시킨다면 아무 것도 얻을 수 없지만 다른 채널을 통해 비밀번호를 공유하는 데 조금이라도 주의를 기울이면 도적에 대한 추가적인 안전과 보안을 확보할 수 있습니다. , 스누프 및 ne'er-do-wells가 기밀 콘텐츠에 쉽게 액세스할 수 있습니다.
스포트라이트를 받는 OME
아니면 가지고 있습니까?
에 따르면 연구원 핀란드 사이버 보안 회사 WithSecure에서 데이터는 합리적으로 기대할 수 있는 보호 수준이 훨씬 낮을 수 있습니다.
테스터가 사용한 기능은 Office 365 메시지 암호화및 OME 짧게.
우리는 여기서 그들의 실험을 재현하지 않았습니다. 죄송합니다. 핵심 Office 365 제품은 우리가 업무용으로 사용하는 Linux에서 기본적으로 실행되지 않기 때문입니다. 웹 기반 버전의 Office 도구에는 전체 앱과 동일한 기능 세트가 없으므로 얻을 수 있는 결과가 대부분의 Office, ah, 365 비즈니스 사용자가 Word, Excel, Outlook을 구성한 방식과 일치하지 않을 수 있습니다. Windows 노트북을 사용하는 친구들.
연구자들은 다음과 같이 설명합니다.
이 기능은 조직이 안전한 방식으로 조직 내부와 외부의 사람들 간에 암호화된 전자 메일 메시지를 보내고 받을 수 있도록 광고됩니다.
그러나 그들은 또한 다음과 같이 지적합니다.
불행히도 OME 메시지는 안전하지 않은 ECB(Electronic Codebook) 작동 모드에서 암호화됩니다.
ECB 설명
설명하기.
많은 암호화 알고리즘, 특히 고급 암호화 표준 또는 OME가 사용하는 AES는 블록 암호, 개별 비트 또는 바이트를 순서대로 처리하는 대신 한 번에 큰 데이터 청크를 스크램블합니다.
일반적으로 말하자면, 암호는 알고리즘을 구동하는 암호화 크랭크 핸들의 각 회전에서 혼합-다지기-파쇄 및 액체화할 더 많은 입력 데이터를 갖고 있기 때문에 효율성과 보안 모두에 도움이 됩니다. 암호화하려는 데이터를 통해
예를 들어, 핵심 AES 알고리즘은 한 번에 16개의 입력 일반 텍스트 바이트(128비트)를 사용하고 해당 데이터를 암호화 키로 스크램블하여 16개의 암호화된 암호문 출력 바이트를 생성합니다.
(혼동하지 마십시오. 블록 크기 과 키 크기 – AES 암호화 키는 추측할 가능성이 얼마나 되는지에 따라 128비트, 192비트 또는 256비트 길이가 될 수 있지만 알고리즘이 "크랭크"될 때마다 세 가지 키 크기가 모두 128비트 블록에서 작동합니다.)
이것이 의미하는 바는 AES 키(길이에 관계없이)를 선택한 다음 데이터 청크에서 직접 AES 암호를 사용하면…
…그때 동일한 입력 청크를 얻을 때마다 동일한 출력 청크를 얻습니다..
정말 방대한 코드북처럼
그래서 이 직접 작동 모드를 ECB, 짧은 전자 코드 북, 암호화 및 암호 해독을 위한 조회 테이블로 사용할 수 있는 거대한 코드북을 갖고 있는 것과 같기 때문입니다.
(전체 "코드북"은 실생활에서 결코 구성될 수 없습니다. 왜냐하면 2개로 구성된 데이터베이스를 저장해야 하기 때문입니다.128 16 바이트 항목 가능한 각 키에 대해.)
불행히도 특히 컴퓨터 형식의 데이터에서는 사용된 파일 형식 덕분에 특정 데이터 청크의 반복이 불가피한 경우가 많습니다.
예를 들어, 512바이트 경계(디스크에 쓸 때 공통 섹터 크기) 또는 4096바이트 경계(메모리를 예약할 때 공통 할당 단위 크기)에 정렬되도록 데이터 섹션을 일상적으로 채우는 파일은 종종 다음을 포함하는 파일을 생성합니다. XNUMX바이트의 긴 실행.
마찬가지로, 모든 페이지의 머리글과 바닥글과 같이 상용구를 많이 포함하는 텍스트 문서나 전체 회사 이름을 반복적으로 언급하는 경우 반복되는 내용이 많이 포함됩니다.
AES-ECB 암호화 프로세스에서 반복되는 일반 텍스트 청크가 16바이트 경계에 정렬될 때마다 암호화된 출력으로 나타납니다. 정확히 같은 암호문으로.
따라서 암호문 파일을 형식적으로 해독할 수 없더라도 입력의 패턴(알거나 추론할 수 있는 또는 추측)이 출력에 보존됩니다.
다음은 거의 XNUMX년 전에 Adobe가 사용자 암호를 "해시"하기 위해 ECB 모드 암호화를 사용하는 것으로 악명 높은 이유를 설명한 기사를 기반으로 한 예입니다. 좋은 생각이 아니다:
권리. AES-128-ECB로 암호화된 이미지 데이터.
입력에서 흰색으로 표시되는 픽셀이 출력에서 반복적인 패턴을 안정적으로 생성하고 파란색 부분이 약간 규칙적으로 유지되어 원본 데이터의 구조가 명확하다는 점에 유의하십시오.
이 예에서 원본 파일의 각 픽셀은 정확히 4바이트를 차지하므로 입력 데이터에서 왼쪽에서 오른쪽으로 실행되는 각 4픽셀의 길이는 16바이트이며 각 16바이트 AES 암호화 블록과 정확히 일치하므로 "ECB 효과".
암호문 패턴 일치
설상가상으로, 동일한 키로 암호화된 두 개의 문서가 있고 그 중 하나의 일반 텍스트가 있는 경우 암호문을 통해 볼 수 있습니다. 수 없습니다 암호를 해독하고 해당 섹션을 암호문의 패턴과 일치시키십시오. 해독하다.
첫 번째 문서가 이미 해독된 형식으로 있는 경우 첫 번째 문서를 "해독"하는 데 키가 필요하지 않다는 것을 기억하십시오. 알려진 일반 텍스트 공격.
그 자체가 비밀 데이터가 아닌 겉보기에 무해한 텍스트가 몇 개만 있어도 공격자가 이러한 방식으로 추출할 수 있는 지식은 지적 재산권 스파이, 사회 엔지니어, 법의학 수사관 등에게 금광이 될 수 있습니다.
예를 들어, 문서의 세부 사항이 무엇을 참조하는지 모를지라도 여러 파일에 걸쳐 알려진 일반 텍스트 청크를 일치시켜 다음과 같이 명백하게 임의의 문서 모음임을 결정할 수 있습니다.
- 모두 같은 수신자에게 발송되었으며, 각각의 상단에 공통된 인사말이 있다면.
- 같은 프로젝트 참조, 계속 팝업되는 고유 식별 텍스트 문자열이 있는 경우.
- 보안 등급이 동일하고, 다른 것보다 "더 비밀스러운" 것을 분명히 의미하는 것들에 집중하는 데 열중한다면.
무엇을해야 하는가?
ECB 모드를 사용하지 마십시오!
블록 암호를 사용하는 경우 블록 암호 작동 모드 그 :
- IV 또는 초기화 벡터로 알려진 것을 포함합니다. 각 메시지에 대해 무작위로 고유하게 선택됩니다.
- 암호화 프로세스를 의도적으로 조정 반복되는 입력이 매번 다르게 나오도록.
AES를 사용하는 경우 요즘 선택하고 싶은 모드는 다음과 같습니다. AES-GCM (Galois Counter Mode)는 키가 동일하게 유지되더라도 IV를 사용하여 매번 다른 암호화 데이터 스트림을 생성할 뿐만 아니라 메시지 인증 코드 (MAC) 또는 암호화 체크섬, 데이터 스크램블링 또는 스크램블 해제와 동시에.
AES-GCM은 반복되는 암호문 패턴을 피할 뿐만 아니라 방금 복호화한 데이터가 도중에 변조되었는지 여부를 알려주는 "체크섬"이 항상 표시된다는 것을 의미합니다.
암호문이 실제로 무엇을 의미하는지 모르는 사기꾼은 그럼에도 불구하고 어떤 종류의 잘못된 결과가 나오는지 알지(또는 신경 쓰지 않고) 부정확한 암호 해독을 믿도록 속일 수 있습니다.
동일한 키와 IV를 기반으로 복호화 프로세스 중에 계산되는 MAC은 수신한 암호문이 유효하다는 것을 확인하는 데 도움이 됩니다.
또는 전용 스트림 암호 한 번에 16바이트(또는 블록 크기가 무엇이든)를 처리하지 않고도 데이터를 암호화할 수 있는 의사 난수 바이트 단위 키스트림을 생성합니다.
AES-GCM은 기본적으로 AES를 스트림 암호로 변환하고 MAC 형식의 인증을 추가하지만, 이러한 방식으로 작동하도록 특별히 설계된 전용 스트림 암호를 찾고 있다면 Daniel Bernstein의 차차20-폴리1305 (Poly1305 부분은 MAC임), RFC 8439.
아래에서 AES-128-GCM 및 ChaCha20-Poly1305(여기서 MAC 코드는 버렸음)를 사용하여 얻은 결과와 Linux 커널 의사 난수 생성기.
데이터가 구조화되지 않은 것처럼 보인다고 해서 그것이 진정으로 무작위적이라는 의미는 아니지만 무작위로 보이지 않지만 암호화되었다고 주장한다면 뒤에 구조가 남아 있고 암호화가 다음과 같다고 가정하는 것이 좋습니다. 의심하다:
결론은 어떻게되는데?
WithSecure에 따르면, Microsoft는 Office 2010과의 이전 버전과의 호환성을 이유로 이 "취약점"을 수정할 계획이 없습니다...
레거시 버전의 Office(2010)에는 AES 128 ECB가 필요하며 Office 문서는 여전히 Office 앱에서 이러한 방식으로 보호됩니다.
…과…
[WithSecure 연구원의] 보고서는 보안 서비스에 대한 기준을 충족하는 것으로 간주되지 않으며 위반으로 간주되지도 않습니다. 코드가 변경되지 않았으므로 이 보고서에 대해 CVE가 발행되지 않았습니다.
간단히 말해서, 현재 OME에 의존하고 있다면 민감한 메시지를 위한 타사 암호화 도구로 교체하는 것을 고려할 수 있습니다. Office 범위의 코드입니다.
이렇게 하면 Office 2010에 내장된 구식 암호 해독 코드로 돌아갈 필요 없이 최신 암호 및 최신 암호 작업 모드를 선택할 수 있습니다.
기사에서 이미지를 만든 방법 sop330.png로 시작합니다. 이 파일은 최상단 이미지에서 정리된 SOPHOS 로고를 자르고 2픽셀 파란색 경계를 제거하고 PNG 형식으로 저장하여 직접 만들 수 있습니다. 이미지의 크기는 330x72픽셀이어야 합니다.
ImageMagick을 사용하여 RGBA로 변환: $ convert sop330.png sop.rgba 출력은 330x72 픽셀 x 4바이트/픽셀 = 95,040바이트입니다.
=== Lua 및 LuaOSSL 라이브러리를 사용하여 암호화(Python은 OpenSSL 바인딩과 매우 유사함): -- 데이터 로드 > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- 암호 객체 생성 > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- 암호 및 IV 초기화 -- AES-128-ECB에는 128비트 암호가 필요하지만 IV는 필요하지 않습니다. -- AES-128-GCM에는 128비트 암호와 12바이트 IV가 필요합니다. -- ChaCha20에는 256비트 암호가 필요하고 a 12바이트 IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- 95040개의 파일 데이터를 암호화 > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- 스트림 암호는 출력을 바이트 단위로 생성하므로 -- 암호문은 일반 텍스트와 길이가 같아야 합니다. > gcmout:len() 95040 > chaout:len() 1305 -- 여기서는 GCM 및 Poly128의 MAC 코드를 사용하지 않겠지만 -- 각 암호는 16비트(16바이트) "체크섬"을 생성합니다. -- 암호 해독이 완료된 후 이를 인증하는 데 사용되며 -- 입력 암호 텍스트가 손상되거나 해킹되었는지 감지합니다 -- (MAC는 키에 따라 다르므로 / 공격자는 위조할 수 없음) > base.hex(gcm:getTag(70)) a204605f5cd18bd9c4e36da9cbc74e16 > base.hex(cha:getTag(55)) a97b5d9e3f9cb3a2be4fa040f56 create from "imagerandom" misc.filetostr('/dev/random',#fdat) -- 모두 저장 - AES-ECB를 명시적으로 자릅니다 -- 암호 출력을 필요한 정확한 이미지 길이로 차단합니다. -- ECB는 일치하기 위해 패딩이 필요하기 때문입니다. 블록 크기로 입력 크기 > misc.strtofile(aesout:sub(95040,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndout,'rnd.rgba') === 일반 이미지 뷰어에서 파일을 로드하려면 손실 없이 다시 PNG 형식으로 변환해야 할 수도 있습니다. $ convert -depth 1 -size 8x330 aes .rgba aes.png $ 변환 -깊이 72 -크기 8x330 gcm.rgba gcm.png $ convert -depth 72 -size 8x330 cha.rgba cha.png $ convert -depth 72 -size 8x330 rnd.rgba rnd.png === 암호화 프로세스가 각 RGBA 픽셀에서 72바이트를 모두 스크램블한다고 가정할 때 , 결과 이미지는 가변 투명도를 갖습니다(A = 알파, 투명도의 약자).
이미지 뷰어는 이러한 종류의 이미지를 바둑판 배경으로 표시하기로 결정할 수 있습니다. 이 이미지는 혼란스럽게 이미지의 일부처럼 보이지만 그렇지 않습니다. 따라서 암호화된 파일을 더 쉽게 볼 수 있도록 원본 이미지의 Sophos 파란색을 배경으로 사용했습니다. 따라서 전체 파란색 색조는 이미지 데이터의 일부가 아닙니다.
