어제, 오늘 그리고 내일

이번 포스팅은 x.509 인증서에 대하여 알아보도록 하겠습니다.

1. X.509 인증서 정의

CA가 인증서를 발급할 때, 인증서에 들어가는 항목의 종류와 항목의 값들을 CA 나름대로 기입한다면 인증서를 사용하는 사용자마다 다른 형식의 인증서를 가지고 있을 것이기 때문에 인증서의 내용을 이해하는데 문제가 있을 것입니다.

따라서 인증서를 작성함에 있어서 어떤 표준이 있어야 합니다. 현재 가장 널리 사용되고 있는 공개키 인증서의 표준은 X.509 형식 입니다. X.509라는  것은 표준 번호입니다. 그래서 이 형식대로 작성된 인증서를 X.509 라고 부르는 것입니다.

X.509 인증서란 이름은 1988년에 CCITT에서 발행된 문서로부터 처음 알려지게 되었습니다. 현재 X.509 인증서는 버전 3까지 발표된 상태입니다. 버전 3인 X.509 인증서를 “X.509 v3”이라고. 그리고 이 X.509 인증서는 IETF에 의해 현재 인터넷의 표준 인증서 형식으로 정해지게 되었습니다.

2. X.509 인증서 항목

현재 X.509 인증서의 버전은 3이라고 했습니다. 이 버전3의 X.509 인증서와 이전의 X.509 인증서와 다른 점은 버전 3에는 Extension이라고 하는 섹션이 추가되었다는 것입니다. 이 Extension 섹션은 여러 개의 항목으로 구성되어 있는데, 필수 적인 항목이 아니라 추가적인 사항을 나타내는 항목들로 구성되어 있습니다.

그럼 자세히 X.509 인증서(버전 3)에 들어가는 항목을 알아보겠습니다. Extension 항목은 중요한 것만 설명했습니다..

위의 표의 항목 중에 주체의 정보와 발급자의 정보에 해당하는 항목이 있습니다. 이 항목에는 DN (distinguished name) 형식으로 주체와 발급자의 정보를 넣게 됩니다. DN의 항목들과 설명은 다음 표와 같습니다.

위 표의 예를 사용해서 실제로 X.509 인증서에 들어가는 subject 항목에 대한 값을 구성하면 다음과 같습니다.

이런 형식으로 주체와 발급자의 정보를 인증서안에 표시하게 됩니다.

앞서 설명한 X.509 인증서의 항목에 대한 값들이 실제 인증서에 어떻게 들어가 있나 살펴보시기 바랍니다.

3. X.509 인증서가 저장되는 여러 가지 형식들

앞에서 X.509 인증서의 실제 모습을 보았습니다. 하지만 사실 X.509 인증서는 앞에서 본 모습대로 저장되는 것은 아닙니다.

앞에서 본 인증서의 모습은 사람이 보기 편하게 X.509 인증서의 내용을 재 구성한 것입니다. 하지만 실제의 인증서는 위의 예에서처럼 사람이 보기 편하게 텍스트 형식으로 저장되지 않습니다.

X.509 표준의 인증서 형식은 ASN.1 (Abstract Syntax Notation One)이라는  명명 규칙을 따릅니다. 그런데 이 ASN.1 표기 방식은 매우 복잡합니다. ASN.1 은 C 언어 같은 프로그래밍 언어와 비슷합니다. 많은 변수 형식이 있고, 많은 구조체 데이터 저장 형식이 있습니다. 인증서의 각 항목은 OID라는 일련번호로 나타낼 수 있으며 항목의 데이터는 ASN.1 타입의 데이터로 표현됩니다..

이러한 이유로 ASN.1 형식에 대한 자세한 설명은 하지 않겠습니다. X.509 인증서의 각 항목의 내용은 ASN.1의 형식에 맞게 저장된다고만 알아 두시면 되겠습니다.

대신 실제로 우리가 앞으로 인증서를 사용할 때 자주 보는 파일 저장 형식에 관해서 설명하겠습니다.그것은 PEM 형식과 DER 형식입니다.

ASN.1 형식으로 되어 있는 X.509 인증서의 내용을 파일로 저장할 때 주로 두 가지 종류의 형식으로 저장합니다. 

첫 번째는 X.509 인증서 내용을 base64 encoding으로 인코딩하여 저장하는 것입니다. 

두 번째는 X.509 인증서 내용을 바이너리 형태로 저장하는 것입니다. 

첫 번째 형식을 PEM, 두 번째 형식을 DER이라고 합니다.

원래 PEM은 암호화된 메일을 나타내는 확장자입니다. DER과 PEM의 차이는 위에서 설명했던 ASN.1 형식으로 되어 있는 X.509 인증서 내용을 base64 encoding으로 인코딩하여 저장하는 것 과 X.509 인증서 내용을 바이너리 형태로 저장 하는 것의 차이입니다..

그럼 실제로 어떤 모습으로 저장되는지 보겠습니다.

PEM 형식은 영문자와 숫자, 그리고 몇 개의 기호로만 저장되기 때문에 사람이 보기에 편하고 다루기 쉽다는 장점이 있습니다. 따라서 앞으로 우리가 인증서나 공개키 같은 내용을 파일로 저장할 때에는 주로 PEM형식으로 저장하게 될 것입니다.

Reference

1. https://blog.naver.com/nttkak/20130245553

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

1.  패딩 (Padding)

패딩에 대하여 알아보기에 앞서 PKCS#5과 PKCS#7은 패딩(Padding)에 관련된 표준이라는 사실을 알아두고 시작하는 것이 좋습니다.

"Padding"은 데이터를 특정 크기로 맞추기 위해 그 크기보다 부족한 부분을 뭔가로 채워넣는 작업을 가리키는 일반 용어입니다.

PKCS#5는 Password 기반 암호화 표준(Password-based Encryption Standard)라고 명명되어 있고, 현대 공인인증 방식은 이 PKCS#5 표준에 따라 개인 Password를 그 근간으로 하고 있습니다. 즉, Password로 표현할 수 있는 Key를 사용하는 암호화 표준이라는 것입니다.

Password란 우리가 보통 알고 있는 영문, 숫자, 특수문자를 포함해서 키보드 상에서 [input type="password"] 형식으로 쓸 수 있는 모든 문자를 말합니다. 넓은 의미로는 1 바이트로 표현 가능한 모든 문자, 즉 ASCII 코드로는 0~255 (이진수로 00000000부터 11111111까지)에 해당됩니다. (그러나 앞 부분의 컨트롤 문자와 뒷부분의 확장 문자 코드를 빼면 32~126 사이의 문자 코드만 해당된다.) 이걸 이진수로 표현하면 최대 8자리의 숫자로 표현되기 때문에 8진 문자열(Octet string) 이라고도 표현합니다.

즉, "1 바이트 = 1 octet" 이 되는 것입니다. 

이 8진 문자열을 사용하는 것에 대한 표준이 바로 PKCS#5입니다.

[참조] PKCS#5 - Password-based Encryption Standard (rfc 2898 문서)

위 참조 문서의 6.1.1 부분에 그 핵심 내용이 들어있습니다.

바로, 패딩(padding)입니다. 8바이트 기준 패딩입니다. 이것이 PKCS#5의 핵심입니다. 

즉, 평문의 길이가 8바이트의 배수를 기준으로 모자라는 수 만큼의 숫자를 채워서 8바이트의 배수로 길이를 맞추는 작업에 대한 것입니다.

여기서 주의해야 할 점은 이 Padding은 반드시 발생해야 한다는 것을 잊어버리고 8바이트보다 작은 경우에만 적용하는 실수를 하는 경우가 있습니다.  8바이트의 배수인 경우에도 Padding은 무조건 해야 합니다. 

위 문서의 6.1.1 부분에도 명시되어 있지만 한글로 더 잘 설명된 내용이 아래 링크에 있습니다.

[참고] http://manual-archive.blogspot.kr/2012/03/pkcs-padding-method_19.html

예제까지 포함하여 설명된 내용이 아래 링크에 있습니다.

[참고] http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.csfb400/pkcspad.htm

이 PKCS#5는 DES, TripleDES 등 8바이트 블럭 암호화 기반 기존 알고리즘들에 잘 적용되었던 표준입니다. 그런데 이후 128비트(16바이트) 이상의 블럭 암호화 알고리즘들이 속속 발표되면서 이 패딩 방식에 대한 표준도 확장이 필요하게 되었습니다. 그래서 나온 것이 PKCS#7 입니다.

[참조] PKCS#7 - Cryptographic Message Syntax Standard (rfc 2315)

위 참조 문서의 핵심 내용은 10.3 부분에 있습니다.

즉, 암호화 블럭 크기가 k바이트인 경우 k바이트보다 작거나 같은 경우 패딩을 적용하라는 것입니다. 

AES의 경우 16바이트 암호화 블럭이 사용되는 알고리즘이므로 16바이트 패딩이 적용됩니다.

2. 모드(Mode) / IV(초기화 벡터; Initialization Vector)

Mode는 간단히 이야기하면, 블럭 암호화 순서 및 규칙에 대한 표준입니다.

Mode에 대한 설명은 아래 링크에 중요한 내용이 다 나와 있으니 참조하시면 됩니다.

[참조] http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

위 링크에 자세히 나와 있지만 일반적으로 가장 많이 쓰이는 CBC(Cipher-Block Chaining) 모드에 대해 간단히 반복 설명하자면, 최초 평문 1블럭과 IV(초기화 벡터)를 XOR 연산한 다음 암호화하고, 다음 평문 1블럭은 앞에서 암호화된 결과 블럭과 XOR 연산하여 다시 암호화합니다.

위의 과정을 끝까지 반복하는 것이 CBC 모드입니다.

(평문 마지막 블럭은 패딩된 블럭입니다.)

CBC 모드는 IV를 사용하지 않고, 즉 XOR 연산 없이 각 블럭을 암호화만 하는 모드인 ECB 모드에 비해 훨씬 더 강력한 암호화 기법입니다.

Reference

https://mm4mm.tistory.com/m/27

이번 포스팅은 Android KeyChain을 사용하여 대칭키를 안전하게 저장하는 방법에 대하여 알아보도록 하겠습니다.

Android KeyChain API를 사용하여 대칭 키를 저장하는 안전한 방법은 다음과 같습니다.

Part 1.  Key 생성 및 저장

1. 대칭키를 생성합니다.
2. Android Keystore에서 비대칭키를 생성합니다.
3. 2번에서 생성한 비대칭키의 공개키(Public Key)를 사용하여 대칭키를 암호화합니다. 

    encrypted_symmetric_key = public_encrypt (symmetric_key)

4. 앱 내에 암호화된 대칭키를 저장합니다.

Part.2  대칭키를 사용 

원문을 암복호화할 경우에 사용합니다.

1. Android KeyStore에서 비 대칭키의 개인키(PrivateKey)를 메모리로 로드합니다.
2. 앱 내에 암호화된 대칭키를 디스크에서 로드합니다.
3. 1번에서 로드한 개인키(PrivateKey)로 암호화된 대칭키를 복호화합니다.

    symmetric_key = private_decrypt (encrypted_symmetric_key)

4. 복호화된 대칭키로 원문을 암호화 나 복호화를 진행합니다.

Reference

https://codeday.me/ko/qa/20190503/453287.html

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

대칭키 암호

대칭키 암호(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