반응형

이번 포스팅은 Android Build 오류에 대하여 알아보도록 하겠습니다.


< Error>


WARNING: API 'variant.getMergeResources()' is obsolete and has been replaced with 'variant.getMergeResourcesProvider()'.

It will be removed at the end of 2019.

For more information, see https://d.android.com/r/tools/task-configuration-avoidance.

REASON: It is currently called from the following trace:


< Solution >


1. 'com.google.gms:google-services:4.3.0'에서 오류가 발생하였습니다.

   gms 라이브러리 내부적으로 발생하는 오류로써 향후 수정이 되어 배포될 것입니다.

2. 임시방편으로 build.gradle의 gms 라이브러리 버전을 downgrade 하여 아래와 같이 수정하면 오류 없이 정상적으로 Build가 될 것 입니다.

dependencies {
classpath 'com.android.tools.build:gradle:3.4.2'
classpath 'com.google.gms:google-services:4.2.0'
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}


반응형
반응형

이번 포스팅은 대칭키 암호화에 대하여 알아보도록 하겠습니다.

 

대칭키 암호

대칭키 암호(Symmetric key)란 암호문을 생성(암호화)할 때와 암호문으로부터 평문을 복원할 때 사용하는 키가 동일한 암호 시스템으로 일반적으로 알고 있는 암호 시스템입니다. 대칭키는 송신자와 수신자가 같은 키를 보유하고 그 키를 통해 송신자가 평문을 암호화해서 전송하면 수신자가 같은 키로 복호화합니다이러한 대칭키 암호 방식은 데이터를 변환하는 방법에 따라서 Block 암호와 Stream 암호로 구별합니다.

 

대칭키의 장점과 단점

장점

 키 크기가 상대적으로 작습니다. 

▶ 암호 알고리즘 내부 구조가 단순하여, 시스템개발 환경에 유리합니다.

 비대칭키에 비해 암호화와 복호화 속도가 빠릅니다.

단점

 교환 당사자간에 동일한 키를 공유해야 하기 때문에 키관리의 어려움이 있습니다.

 잦은 키 변경이 있는 경우에 불편함을 초래합니다. 

 디지털 서명 기법에 적용이 곤란하고 안전성을 분석하기가 어렵습니다.

 중재자가 필요합니다.

 

대칭키 암호 방식

Block 암호(Block Cipher)

▶ 암호문을 만들기 위하여 암호 키와 알고리즘이 데이터 블록 단위로 적용되는 암호화 방법입니다. 평문의 동일 블록들이 하나의 메시지에서 동일한 암호문으로 되지 않도록 하기 위해 이전 암호 블록의 암호문을 다음 블록에 순서대로 적용하는 것입니다. 

▶ 라운드 함수를 사용해 반복적으로 암호화 과정을 행함으로써 암호화 강도를 향상시킵니다. 

▶ 이러한 블록 암호 구조에는 페이스텔(Feistel)구조와 SPN(Substitution-Permutation Network) 구조가 있습니다.

 

Block 암호의 장점

▶ S/W 적으로 구현할 수 있습니다.

▶ 전치와 치환을 반복하여 평문과 암호문으로부터 키에 대한 정보를 쉽게 찾아내기 어렵습니다.

▶ 데이터 전송, 대용량 데이터 저장시 사용이 가능합니다.

 

Block 암호의 단점

▶ 느린 암호화 속도와 에러 전파의 문제가 있습니다.

▶ 데이터의 크기가 작을 경우 효율적으로 암호화 하기에는 적합하지 않습니다.

 

Block 암호의 종류

AES(Advanced Encryption Standard)

 
▶ AES는 미국 표준 블록 암호였던 DES의 안전성에 문제가 제기됨에 따라 2000년 새로운 미국 표준 블록 암호로 채택된 128-비트 블록 암호입니다. AES는 128비트 평문을 128,192,256비트의 세 가지 키를 가지며, 공개 알고리즘으로 누구나 이용 가능합니다. SPN 구조를 사용하여 블록을 나누지 않고 한번에 변화시키는 구조입니다. 
 
▶ AES는 128비트 블록 단위로 암호화를 실행합니다. 
 
Stream 암호(Stream Cipher)
 
▶ 스트림 암호는 데이터 흐름(스트림)을 비트 단위로 순차적으로 처리해가는 암호 알고리즘으로써 원타임패드(One Time Pad)를 실용적으로 구현할 목적으로 개발되었습니다. 
 
▶ 초기 벡터를 암호화 한 후 평문에 XOR 연산을 해 암호문을 구현합니다.
 
Stream 암호의 장점

▶ 오류 확산의 위험이 없고, 하드웨어적 구현이 가능합니다.

▶ 주로 군사 및 외교용으로 사용되었으나, 최근에는 이동통신 환경에서 구현이 용이해 무선 데이터 보호에 이용되고 있습니다.

▶ 실시간성이 중요하게 생각되는 음성, 영상, 스트리밍 전송에 사용됩니다.

 

Stream 

암호의 단점

▶ 비트단위로 암호화하기 때문에 시간이 많이 걸립니다.

▶ 데이터 흐름에 따라 비트 단위로 순차적으로 처리하기 때문에 내부 상태를 저장하고 있어야 합니다.

▶ 평문의 길이가 커지면 키 길이도 커지기 때문에 비효율적입니다.

▶ 선형성으로 인해 공격에 취약합니다.

 

Reference

1.http://wiki.hash.kr/index.php/%EB%8C%80%EC%B9%AD%ED%82%A4_%EC%95%94%ED%98%B8_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98

 

반응형
반응형

이번 포스팅은 PKCS(Public Key Cryptography Standards)에 대하여 알아보도록 하겠습니다.

 

암호학에서 PKCS는  "공개 키 암호화 표준"을 의미합니다. 1990년대 초반부터 RSA Security LLC에서 고안하고 발표 공개 키 암호화 표준  그룹입니다. 이 회사는  RSA 알고리즘  , Schnorr 서명 알고리즘 등 특허권이 있는 암호화 기술의 사용을 촉진하기 위한 표준을 발표하였습니다. 

업계 표준은 아니지만, 최근 몇 년 동안 IETF 및 PKIX 실무 그룹과 같은 관련 표준 조직의 "표준 추적" 프로세스에 일부 표준이 적용되기 시작했습니다.

 

PKCS 표준 요약

  Version Name Comment

PKCS#1

2.2 RSA 암호화 표준 RFC 8017을참조하십시오.

RSA PublicKey 및 PrivateKey의 수학적 속성 및 형식(ASN.1은 일반 텍스트로 인코딩)과 RSA 암호화, 암호 해독 및 서명 생성 및 검증을 위한 기본 알고리즘 및 인코딩 / 패딩 체계를 정의합니다.
PKCS#2 - 사용하지 않음 2010년부터 더 이상 활성화되지 않습니다. 

메시지 요약에 대한 RSA 암호화 적용 이후 PKCS#1로 병합되었습니다.
PKCS#3 1.4 Diffie–Hellman 주요 계약
 표준 
서로에 대한 사전 지식이 없는 두 당사자가 비 보안 채널을 통해 공유 SecretKey를 공동으로 설정할 수 있도록하는 암호화 프로토콜입니다.
PKCS#4 - 사용하지 않음 2010년부터 더 이상 활성화되지 않습니다 . 
RSA 키 구문을 검색한 후 PKCS#1로 병합했습니다.
PKCS#5 2.1 비밀번호 기반 암호화 표준 RFC 8018 PBKDF2를 참조하십시오 .
PKCS#6 1.5 확장 인증서 구문 표준 이전 v1 X.509 인증서 사양 에 대한 확장을 정의합니다. 

동일한 v3에서 사용되지 않습니다.
PKCS#7 1.5 암호화 메시지 구문
 표준
RFC 2315를참조하십시오.

PKI에서 메시지를 서명 및 암호화하는데 사용됩니다. 인증서 배포에도 사용됩니다 (예 : PKCS#10 메시지에 대한 응답).  2010년 현재 업데이트된 CMS(Cryptographic Message Syntax Standard)인 RFC 5652를 기반으로 S/MIME의 기초를 형성했습니다. 단일 로그온에 자주 사용됩니다.

PKCS#8

1.2 개인 키 정보 구문 표준 RFC 5958을참조하십시오.

개인 인증서 키 쌍(암호화되거나 암호화되지 않음)을 운반하는 데 사용됩니다. 
PKCS#9 2.0 선택된 속성 유형 RFC 2985를참조하십시오.

PKCS#6 확장 인증서, PKCS#7 디지털 서명 메시지, PKCS#8 개인 키 정보 및 PKCS#10 인증서 서명 요청에 사용할 선택한 특성 유형을 정의합니다. 

PKCS#10

1.7 인증 요청 표준 RFC 2986을참조하십시오. 

PublicKey 인증을 요청하기 위해 인증 기관에 보낸 메시지 형식입니다. 

인증서 서명 요청을 참조하십시오.

PKCS#11

2.40 암호화 토큰 인터페이스 "Cryptoki"라고도합니다. 
암호화 토큰에 대한 일반 인터페이스를 정의하는 API입니다.
( 하드웨어 보안 모듈 참조 ). 

SSO , 공개 키 암호화  디스크 암호화 시스템 에서 종종 사용됩니다.

RSA Security는 PKCS#11 표준의 추가 개발을 OASIS PKCS 11 기술위원회에 맡겼습니다.

PKCS#12

1.1 개인 정보 교환 구문 표준 RFC 7292를참조하십시오 . 
암호 기반 대칭키로 보호되는 공개 키 인증서와 함께 PrivateKey

를 저장하는데 일반적으로 사용되는 파일 형식을 정의합니다. 

PFX는 PKCS#12의 전신입니다.

이 컨테이너 형식에는 여러 인증서와 같은 여러 내장 개체가 포함될 수 있습니다. 일반적으로 암호로 보호/암호화됩니다.

Java 키 저장소 Mozilla Firefox에서 에서 클라이언트 인증 인증서를 설정하는 형식으로 사용할 수 있습니다. 

아파치 톰캣에서 사용할 수 있습니다. 
PKCS#13 타원 곡선 암호화
 표준
(분명히 폐기되었으며 1998 의 제안을 오직 참조만 할 수 있습니다.) 
PKCS#14 의사 난수 생성 (분명히 폐기되었으며 문서가 없습니다.)
PKCS#15 1.1 암호화 토큰 정보 형식 표준 암호화 토큰의 사용자가 애플리케이션의 Cryptoki 구현(PKCS #11) 또는 기타 API에 관계없이 애플리케이션에 대해 자신을 식별할 수 있는 표준을 정의합니다.
RSA는 이 표준의 IC 카드 관련 부분을 ISO/IEC 7816-15에 양도했습니다.

Reference

 

1. https://en.wikipedia.org/wiki/PKCS

 

반응형

+ Recent posts