어제, 오늘 그리고 내일

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

대칭키 암호

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

대칭키의 장점과 단점

장점

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

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

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

단점

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

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

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

▶ 중재자가 필요합니다.

대칭키 암호 방식

Block 암호(Block Cipher)

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

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

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

Block 암호의 장점

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

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

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

Block 암호의 단점

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

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

Block 암호의 종류

AES(Advanced Encryption Standard)

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

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

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

Reference

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

이번 포스팅은 중요한(민감한) 데이터를 어떻게 Android 내에서 접근을 통제하고 요구 사항을 확인하는지 알아보도록 하겠습니다.

중요한(민감한) 데이터 Access permission

권한의 목적은 Android 사용자의 Privacy를 보호하는 것입니다.  Android 앱은 특정 시스템 기능(예: 카메라, 인터넷 등)뿐만 아니라 민감한 사용자 데이터(예: 연락처, SMS 등)에 접근할 수있는 권한을 요청해야 합니다. 기능에 따라 시스템이 자동으로 권한을 부여하거나 사용자에게 요청을 승인하도록 요청 할 수 있습니다.

Android 보안 아키텍처의 핵심 설계 포인트는 기본적으로 어떤 앱도 다른 앱, 운영 체제 또는 사용자에게 부정적인 영향을 미칠 수 있는 작업을 수행할 수 있는 권한을 가지고 있지 않다는 것입니다. 여기에는 연락처 또는 전자 메일과 같은 사용자의 개인 데이터 읽기 또는 쓰기, 다른 앱의 파일 읽기 또는 쓰기, 네트워크 액세스 수행, 장치 절전 모드 유지 등이 포함됩니다.

이 페이지에서는 Android 사용 권한이 사용자에게 제공되는 방법, 설치 시간과 런타임 사용 권한 요청 간의 차이, 사용 권한 적용 방법, 사용 권한 및 해당 그룹의 유형을 비롯하여 Android 사용 권한의 작동 방법에 대해 간략히 설명합니다. 앱 사용 권한을 사용하는 방법 안내서를 원하는 경우 대신 애플리케이션 사용 권한 요청을 참조하십시오.

허가 승인

앱은 AndroidMenifest에 <uses-permission> 태그를 포함하여 필요한 권한을 공개해야 합니다. 예를 들어 SMS 메시지를 보내야하는 앱은 AndroidMenifest에 다음 선언문이 있습니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.snazzyapp">

    <uses-permission android:name="android.permission.SEND_SMS"/>

    <application ...>
        ...
    </application>
</manifest>

앱이 AndroidMenifest에 일반 권한 (즉, 사용자의 개인 정보 보호 또는 기기 작동에 큰 위험을 주지 않는 권한)을 표시하면 시스템은 자동으로 앱에 해당 권한을 부여합니다.

앱이 AndroidMenifest에 위의 SEND_SMS 권한과 같이 위험한 권한 (즉, 사용자의 개인 정보 보호 또는 기기의 정상적인 작동에 영향을 줄 수있는 권한)을 표시하는 사용자는 해당 권한을 부여하는 데 명시적으로 동의해야 합니다.

일반 권한 및 위험 권한에 대한 자세한 내용은 보호 수준을 참조하십시오.

위험한 권한에 사용 권한을 요청

위험한 권한만 사용자 동의가 필요합니다. Android가 사용자에게 위험한 사용 권한을 부여하도록 요청하는 방법은 사용자의 기기에서 실행되는 Android 버전과 앱에서 대상으로하는 시스템 버전에 따라 다릅니다.

런타임 요청 (Android 6.0 이상)

기기에서 Android 6.0(API 수준 23) 이상을 실행 중이며 앱의 targetSdkVersion 23 이상인 경우 설치 시 사용자에게 앱 사용 권한이 통보되지 않습니다. 앱은 사용자에게 런타임시 위험한 권한을 부여하도록 요청해야합니다. 앱이 권한을 요청하면 사용자에게 앱이 액세스하려는 권한 그룹을 알려주는 시스템 대화 상자가 표시됩니다. 대화 상자에는 거부 및 허용 버튼이 있습니다. 

사용자가 사용 권한 요청을 거부하면 다음에 앱에서 사용 권한을 요청할 때 사용자에게 사용 권한을 다시 요청하지 않음을 나타내는 확인란이 대화상자에 포함됩니다.

사용자가 다시 묻지 않음 확인란을 선택하고 거부 를 누르면 나중에 동일한 권한을 요청하려고 할 때 시스템에서 더 이상 메시지를 표시하지 않습니다.

사용자가 요청한 사용 권한을 앱에 부여하더라도 항상 앱에 의존 할 수는 없습니다. 또한 사용자는 시스템 설정에서 사용 권한을 하나씩 활성화 및 비활성화 할 수 있습니다. 런타임 오류 ( SecurityException) 를 방지하려면 항상 런타임시 사용 권한을 확인하고 요청해야합니다 .

런타임 사용 권한 요청을 처리하는 방법에 대한 자세한 내용은 앱 권한 요청을 참조하십시오.

런타임 요청 (Android 5.1.1 이하)

장치가 안드로이드 5.1.1 (API 레벨 22) 이하를 실행중이거나 응용 프로그램의 targetSdkVersion 이 (22) 이하인 경우 시스템은 사용자에게 설치 시 앱에 대한 모든 위험한 사용 권한을 부여하도록 자동으로 요청합니다.

사용자가 수락을 클릭하면 앱 요청에 대한 모든 사용 권한이 부여됩니다. 사용자가 권한 요청을 거부하면 시스템에서 앱 설치를 취소합니다.

앱 업데이트에 추가 사용 권한이 필요한 경우 사용자에게 앱을 업데이트하기 전에 해당 새 사용 권한을 수락하라는 메시지가 표시됩니다.

사용 권한 요청에 대한 권장되는 사용자 경험 패턴에 대한 개요는 앱 권한 모범 사례를 참조하십시오.

사용자에게 사용 권한을 확인하고 요청하는 방법에 대한 자세한 내용은 앱 사용 권한 요청을 참조하십시오.

민감한 사용자 정보에 액세스 하라는 메시지 요청

일부 앱은 통화 로그 및 SMS 메시지와 관련된 민감한 사용자 정보에 대한 액세스에 의존합니다. 로그 및 SMS 메시지를 호출하고 앱을 Play Store에 게시할 권한을 요청하려면 이러한 런타임 권한을 요청하기 전에 사용자에게 앱을 핵심시스템 기능의 기본 처리기로 설정하라는 메시지를 표시해야 합니다.

사용자에게 기본 핸들러 프롬프트 표시에 대한 지침을 포함하여 기본 핸들러에 대한 자세한 정보는 기본 핸들러에서만 사용되는 사용 권한에 대한 모범 사례를 참조하십시오. 

선택적 하드웨어 기능에 대한 사용 권한

일부 하드웨어 기능 (예 : Bluetooth 또는 카메라)에 액세스하려면 앱 사용 권한이 필요합니다. 그러나 모든 Android 기기에 실제로 이러한 하드웨어 기능을 가지고 있는 것은 아닙니다. 따라서 앱에서 CAMERA권한을 요청하는 경우 <uses-feature>태그를 AndroidMenifest에 포함하여 이 기능이 실제로 필요한지 여부를 선언하는 것이 중요합니다. 예를 들면 다음과 같습니다.

android:required="false"기능 을 선언하면 Google Play에서 해당 기능이 없는 기기에 앱을 설치할 수 있습니다. 그런 다음 PackageManager.hasSystemFeature()호출하여 런타임시 현재 장치에 기능이 있는지 확인하고 해당 기능을 사용할 수 없으면 정상적으로 비활성화해야합니다.

<uses-feature>태그를 제공하지 않으면 Google Play에서 앱이 해당 사용 권한 요청을 확인하면 앱에 이 기능이 필요하다고 가정합니다. 따라서 android:required="true"태그에서 선언한 것처럼 기능이 없는 장치에서 앱을 필터링합니다.

자세한 내용은 Google Play 및 기능 기반 필터링을 참조하십시오.

사용 권한 시행

사용 권한은 시스템 기능만을 요청하기 위한 것이 아닙니다. 앱에서 제공하는 서비스는 사용자가 지정 권한을 부여하여 누가 해당 서비스를 사용할 수 있는지 제한 할 수 있습니다. 사용자 지정 사용 권한을 선언하는 방법에 대한 자세한 내용은 사용자 정의 앱 권한 정의를 참조하십시오.

Activity 사용 권한 허용

android:permission속성을 사용하여 AndroidMenifest 에서 <activity> 태그에 적용된 사용 권한은 해당 속성을 시작할 수있는 사용자를 제한합니다. 사용 권한은Context.startActivity() 및 Activity.startActivityForResult()중에 점검이 됩니다. 발신자에게 필요한 권한이 없으면 호출에서 SecurityException 예외가 발생합니다.

Service 사용 권한 허용

android:permission속성을 사용하여 AndroidMenifest 에서 <service> 태그에 적용된 사용 권한은 관련 서비스를 시작하거나 바인딩할 수 있는 사용자를 제한합니다. 사용 권한은 Context.startService(), Context.stopService() 및 Context.bindService() 중에 점검이 됩니다. 발신자에게 필요한 권한이 없으면 호출에서 SecurityException 예외가 발생합니다.

BroadCast 사용 권한 허용

 android:permission 속성을 사용하여 <receiver> 태그에 적용되는 사용 권한은 연결된 BroadcastReceiver로 broadcast 보낼 수 있는 사용자를 제한합니다. 시스템이 제출된 브로드 캐스트를 지정된 수신자에게 전달하려고 시도하므로 Context.sendBroadcast()가 리턴 된 후 권한이 점검됩니다. 결과적으로 권한 실패로 인해 호출자에게 예외가 발생하지 않습니다. 그것은 단지 Intent를 전달하지 않습니다.

마찬가지로, 프로그래밍 방식으로 등록된 수신자에게 브로드캐스트할 수 있는 사용자를 제어하는 권한을 Context.registerReceiver()에 권한을 제공할 수 있습니다. 반대로 Context.sendBroadcast()를 호출 할 때 브로드 캐스트를 수신 할 수있는 브로드 캐스트 수신자를 제한하기 위해 권한을 제공 할 수 있습니다.

수신기와 브로드 캐스터 모두 권한이 필요할 수 있습니다. 이러한 상황이 발생하면 Intent가 연관된 대상으로 전달되도록 두 권한 점검을 모두 통과해야합니다. 자세한 내용은 권한이 있는 브로드 캐스트 제한을 참조하십시오.

Reference

1. https://developer.android.com/games/develop/permissions?hl=en