Contents of Response APDU

DataLrResponse data stringOptional
SW11Status byte 1Mandatory
SW21Status byte 2Mandatory

SW1, SW2를 Status Word라 부르며, 다음과 같은 응답값을 가진다.

Normal processing

9000- Normal ending of the command
91XX- Normal ending of the command, with extra information from the proactive UICC containing a command for the terminal. Length 'XX' of the response data.
92XX- Normal ending of the command, with extra information concerning an ongoing data transfer session.

Postponed processing

9300- SIM Application Toolkit is busy. Command cannot be executed at present, further normal commands are allowed.


6200- No information given, state of non volatile memory unchanged.
6281- Part of returned data may be corrupted.
6282- End of file/record reached before reading Le bytes.
6283- Selected file invalidated.
6285- Selected file in termination state.
62F1- More data available.
62F2- More data available and proactive command pending.
62F3- Response data available.
63F1- More data expected.
63F2- More data expected and proactive command pending.
63CX- Command successful but after using an internal update retry roution 'X' times
- Verification failed, 'X' retries remaining (see note)
NOTE:For the VERIFY PIN command, SW1SW2 indicates that the command was successful but the PIN was not correct and there are 'X' retries left. For all other commands it indicates the number of internal retries performed by the card to complete the command.

Execution errors

6400- No information given, state of non-volatile memory unchanged.
6500- No information given, state of non-volatile memory changed.
6581- Memory problem.

Checking errors

6700- Wrong length
67XX- The interpretation of this status word is command dependent, except for SW2 = '00'
6B00- Wrong parameter(s) P1-P2
6D00- Instruction code not supported or invalid.
6E00- Class not supported.
6F00- Technical problem, no precise diagnosis.
6FXX- The interpretation of this status word is command dependent, except for SW2 = '00'

Functions in CLA not supported

6800- No information given
6881- Logical channel not supported
6882- Secure messaging not supported

Command not allowed

6900- No information given
6981- Command incompatible with fire structure
6982- Secure status not satisfied
6983- Authentication/PIN method blocked
6984- Referenced data invalidated
6985- Conditions of use not satisfied
6986- Command not allowed (no EF selected)
6989- Command not allowed - secure channel - security not satisfied

Wrong parameters

6A80- Incorrect parameters in the data field.
6A81- Function not supported.
6A82- File not found.
6A83- Record not found.
6A84- Not enough memory space.
6A86- Incorrect parameters P1 to P2.
6A87- Lc inconsistent with P1 to P2.
6A88- Referenced data not found.

Application errors

9850- INCREASE cannot be performed, max value reached.
9862- Authentication error, application specific.
9863- Security session or association expired.
NOTE:Applications may define their own error codes.

저작자 표시 비영리 변경 금지

머 먹고 사냐.....

받은 트랙백이 없고 , 댓글이 없습니다.

PPP 등에서 사용하는 인증용 프로토콜 중의 하나

ㅇ 동작방식 : Three-way Handshaking (3 단계 핸드세이킹) 방식

    ① Challenge 메세지 

        . 인증 서버는 클라이언트에게 Challenge 메세지를 보내고, 그 질문에 대한 올바른 응답을 요청

    ② 응답

        . 클라이언트는 보안을 위해 해쉬 함수를 이용하여 계산한 결과 값을 보냄

    ③ 인증 승인 또는 거부

        . 인증 서버는 값이 일치하면 인증을 하게 됨

[Window Side]

  CHAP(Challenge Handshake 인증 프로토콜)는 인증 도중 암호 대신 사용자가 암호를 알고 있다는 메시지를 보내는 방식으로서 광범위하게 지원되는 인증 방법입니다. CHAP를 사용하면 원격 액세스 서버가 원격 액세스 클라이언트로 챌린지 문자열을 보냅니다. 원격 액세스 클라이언트에서는 해시 함수라고도 하는 해시 알고리즘을 사용하여 챌린지 문자열과 사용자 암호에서 계산된 해시 결과를 기초로 MD5(Message Digest-5) 해시 결과를 계산합니다. 원격 액세스 클라이언트는 MD5 해시 결과를 원격 액세스 서버로 보냅니다. 사용자 암호의 해시 결과에도 액세스할 수 있는 원격 액세스 서버는 해시 알고리즘을 사용하여 같은 계산을 수행하고 그 결과를 클라이언트에서 보낸 결과와 비교합니다. 결과가 일치하면 원격 액세스 클라이언트의 자격 증명이 인증된 것으로 간주됩니다. 해시 알고리즘은 데이터 블록의 해시 결과는 쉽게 계산할 수 있지만 해시 결과의 원래 데이터 블록을 수학적으로 파악할 수 없는 단방향 암호화를 제공합니다.

  CHAP에 대한 연결을 구성하려면 ID 인증 및 데이터 암호화 설정 구성을 참조하십시오.


CHAP를 사용하여 연결을 인증하는 경우에는 MPPE(Microsoft 지점간 암호화)를 사용할 수 없습니다.

  CHAP를 사용하여 Windows2000과 라우팅 및 원격 액세스 서비스를 실행하는 원격 액세스 서버에 대한 연결을 인증하는 경우 역방향으로 암호화된 형식으로 암호를 저장할 수 있도록 연결 중인 클라이언트의 사용자 계정을 구성해야 합니다. 역방향으로 암호화된 형식으로 암호를 저장할 수 있도록 사용자 계정을 구성하는 방법에 대한 자세한 내용은 도메인에서 역방향으로 해독 가능한 암호 사용을 참조하십시오.

저작자 표시 비영리 변경 금지

머 먹고 사냐.....

받은 트랙백이 없고 , 댓글이 없습니다.


저작자 표시 비영리 변경 금지

머 먹고 사냐.....

받은 트랙백이 없고 , 댓글이 없습니다.

Step 1. Decode the value of nonce by base 64

nonce            EBP7NsN3GpoTmm2G1/PRA2kQAHNI/rtBAABe2iwhzwRHgQ==

Decoded Data : 1013fb36c3771a9a139a6d86d7f3d1036910007348febb4100005eda2c21cf044781

Step 2. Send the value of nonce to SIM.

nonce : This value is RAND + AUTN from the network.

APDU  : CLA(Channel ID), INS(88), P1(00), P2(81 - See. spec. 31.103 - 7.1.2), Total Length, 

            Data (RAND Length + RAND Data + AUTN Length + AUTN Data)

Step 3. Get Response Data from SIM

The data will have RES, Ck, Ik.

Step 4. The data should be encoded by base64 and then send to Telephony Framework.

Response Data from SIM  

   = DB087673A70B3001927410EAE38418A1A99E24630605DEA687851810810F0C3CD14B62ADE6138A499A57B4BD

Encoded Data by Base64 

   = 2wh2c6cLMAGSdBDq44QYoameJGMGBd6mh4UYEIEPDDzRS2Kt5hOKSZpXtL0=

저작자 표시 비영리 변경 금지

머 먹고 사냐.....

받은 트랙백이 없고 , 댓글  2개가 달렸습니다.
  1. 비밀댓글입니다

When a VoLTE client needs to connect to IMS network, it has to authenticate the network while network also needs to make sure that only the correct user is registered to its network. AKA Digest is one of the scheme to authenticate VoLTE client to the IMS server


AKA stands for "Authentication and key agreement". This scheme comes from the legacy 3gpp networks and has been widely used in LTE, 3G, CDMA and WiMAX technologies. In this mechanism, a secret key is already known to both user device (USIM, iSIM) and authentication servers (HSS, HLR). 

The server will challenge the end user using AKA algorithms and shared key and sends RAND, AUTN values towards UE. UE will authenticate network and prepares result (RES for network to authenticate UE) with the help of shared key in UICC and parameters sent by Server.

HTTP Digest

Http Digest is the popular authentication scheme used for authenticating users to access web servers and other applications which requires security and data integrity. This scheme is much secure than the basic authentication as it applies hash function to the password before sending it [RFC2617]. 

HTTP Digest is username / password based authentication procedure. The authentication server provides one time created " nonce " value to the client. The client uses the nonce value and creates a secure response that contains  the password, username and other parameters to the server. The password which is known both to server and client, is always fixed

Now For IMS

Now since IMS is a part of 3GPP and on the contrary SIP signaling defines http digest for authentication [RFC3261]. Therefore in order to use 3GPP AKA with IMS, the parameters from AKA are mapped onto http digest [RFC3310]. In simple words the parameters / headers used to transport http digest information, will transport AKA information in identical format

With 3GPP AKA digest, the "nonce" now contains RAND, AUTN. The password now contains the one time RESPONSE generated by client with help of UICC (USIM, ISIM). Thus the method is even more secure. 

Authentication in IMS networks

  • VoLTE Client sends SIP register request to IMS Server. The user is not authenticated at this  point. The SIP register request contains IMS related identities (private identity, public identity, URI, etc)
  • The IMS server (S-CSCF) obtains authentication vector and SQN from HSS that contains a random challenge RAND, authentication token AUTN, expected authentication result XRES, a session key for integrity check IK, and a session key for encryption CK
  • The server creates an authentication request, which contains the random challenge RAND, and the network authenticator token AUTN
  • The authentication request is delivered to the client with "401 UNAUTHORIZED" message
  • The client verifies the AUTN with the ISIM. If the verification is successful, the network has been authenticated. The client then produces an authentication response RES, using the shared secret K and the random challenge RAND
3GPP AKA Operation in IMS

  • The authentication response RES is delivered to the server using new regiser sip message
  • The server compares the authentication response RES with the expected response. If the two match, the user has beensuccessfully authenticated
  • Session keys IK and CK can be used for protecting further communications between the client and the server
  • Server sends "200 OK" message to inform the VoLTE client about successful registration

저작자 표시 비영리 변경 금지

머 먹고 사냐.....

받은 트랙백이 없고 , 댓글이 없습니다.