T = 1 스마트 카드 통신 프로토콜과 관련된 질문이 있습니다. 예를 들어, 터미널에서 예상 Ne 데이터가있는 I- 블록을 카드 (소위 케이스 2S)에서 반환하고 카드에 보낼 데이터가 적다 고 가정 해 봅시다. 터미널이 제한 시간까지 기다린 후 마지막 두 바이트 (SW1 및 SW2 상태 여야 함)에 대해 수신 된 내용을 검사해야합니까? 아니면 그 문제와 관련된 다른 시나리오가 있습니까? T = 0 프로토콜의 경우이 문제는 프로 시저 바이트로 처리되지만 T = 1에서는 위의 방법 만 볼 수 있습니다.T = 1 스마트 카드 프로토콜
감사
guidot 어쩌면 그는 전문가가 아니라고 주장하지만, 나는 그를 믿지 않을 것.
Ne 값 (Le를 사용하여 인코딩 됨)은 실제로 반환되는 최대 바이트 수만 나타냅니다. 특정 최대 값의 버퍼 크기를 가질 수도 있고 높은 값 사용을 금지하는 오버 헤드 (보안 메시징)가있을 수도 있습니다. 그러나 APDU 명령을 사용할 수 있습니다 (예 : READ BINARY). 사용 가능한 경우 보내야하는 바이트 양을 나타 내기 위해 Ne가 사용됩니다.
(응답) APDU의 크기는 기본 데이터 링크 계층 (프레임 내의 블록에서 사용 된 체인 비트 및 LEN 바이트)에 의해 결정됩니다. T = 1은 T = 0과 같은 바이트 지향 프로토콜이 아닙니다. T = 1 및 실제로 T = CL의 경우 데이터 링크 계층은 Nc 및 Ne 바이트가있는 응용 프로그램 계층이 아니라 명령 및 응답 APDU의 크기를 결정합니다.
응용 프로그램 계층에서 길이 바이트를 사용하는 것이 유리한 경우 질문을 남깁니다. IMHO ISO/IEC-7816-4는 지금까지 만들어진 최악의 표준 중 하나입니다. 그것은 거의 모든 것을 실현하면서 생각할 수있는 모든 방법으로 빤다. 파일 시스템 기반 카드의 사양에 대한 파일을 읽는 방법에 대한 끊임없는 대화를 갖는 것이 최선의 방법입니다. –
카드는 프롤로그의 LEN 필드에 넣어야한다고 가정합니다. 반환되는 데이터의 양은 얼마입니까?하지만 LEN 필드가 올바르게 수신되면 질문에 답합니다. 그러나 확실하지 않습니다. – Djole
저는 프로토콜 전문가는 아니지만 오해가있는 것 같습니다. Le는 터미널에서 허용 한 최대 * 바이트 수만 나타냅니다. 그것은 더 적을 수도 있습니다. (이것은 정확히 일치해야하는 프로토콜 블록의 LEN 필드와 다르며, 응답 APDU는 전송중인 명령과 완전히 분리되어 있습니다.) LRC 바이트가 나중에 나오는 것은 관련이 없습니다. 블록 지향 프로토콜. – guidot
ISO7816-3에서 나를 잘못 인도 한 이유는 "Ne는 응답 데이터 필드에서 예상되는 최대 바이트 수를 나타냅니다"입니다. 나에게 그것은 기대되는 것이나 더 많이있을 수있는 것처럼 보였다. 문제는 LEN 필드가 손상 될 가능성에 더 관련이 있습니다. LEN 필드가 아직 몇 바이트인지를 나타내는 지표로 사용하려고합니다. 따라서 (LEN)이 손상되어 바이트 수보다 커지면 타임 아웃을 잡는 것이 유일한 방법입니까? 잘못된 LEN의 경우 나중에 올 수있는 체크 바이트에서만 배울 수 있지만 잘못된 LEN을 사용하는 메시지에서는 찾을 수 없습니다. – Djole