Learning the smartcard operating mode and protocol and Parameter Selection of Linux bus driver with cainiao

Mode operation

After the reset response, the card is in one of the following two operation modes:

--
If TA (2) exists, it is in a specific mode;

--
If TA (2) does not exist, it is in the negotiation mode.

The figure shows how to select and switch the card operation mode.

 

1. Specific Mode

In a specific mode, the Protocol indicated by TA (2) should be used directly after the reset response

-- If B5 = 0 in Ta (2), use Fi and di;

-- If B5 = 1 in Ta (2), use an implicit value.

However, IFD can enable hot reset to call the negotiation mode in the card.

 

2. Negotiation Mode

In the negotiation mode, "implicit selection" is possible as long as the first byte sent to the ICC by IFD allows there to be no ambiguity difference between the PPS request and the protocol command.

-- If no PPS request is directly sent after the reset response, FD and DD should be used to apply the "Protocol provided for the first time ";

-- For another protocol provided by ICC and/or other values of parameter F and D (F range: FD to FI, d range: dd to DI ), IFD should send a PPS request using FD and DD to switch from negotiation mode to specific mode. After successful PPS exchange, FN and DN should be used to apply the negotiated Protocol.

If the reset response only provides a protocol (t = 0 to 14) and FD and DD, the protocol should use FD and DD and start immediately after the reset response. Therefore, such a card does not have to support PPS.

IFD that does not support PPs and does not support "1st times of provision protocol", can reset ICC to try to switch from the negotiation mode to the specific mode supported by IFD, or can reject the card.

 

 

Protocol and Parameter Selection (PPS)

PPS requests and responses should be sent in the same way as the reset response, that is, with the same baud rate (So FD and DD are used), in line with the conventions established by ts, the minimum latency is 12etu at the start of two consecutive characters. However, if the interface byte Tc (1) appears in the reset response and is not equal to "FF", additional protection time should be guaranteed. The latency between the start edges of two consecutive characters in the PPS response should not exceed the "Initial wait time"

 

1. PPS Protocol

Only IFD is allowed to start PPS switching.

-- IFD should send a PPS request to ICC;

--
If the ICC receives an incorrect PPS request, it does not send any response;

--
If the ICC receives a correct PPS request, if it completes, it should send a PPS response; otherwise, the initial wait time will be exceeded;

--
If the initial wait time is exceeded, ifd or reset or ICC is rejected;

--
If IFD receives an error PPS response, IFD is reset or ICC is rejected;

If the PPS exchange fails, ifd or reset or ICC is rejected.

 

2. structure and content of PPS requests and responses

The PPS request and response contain an initial PPSS byte, followed by the Format Byte pps0. The three optional Parameter bytes pps1, pps2, pps3, and a test byte PCK are used as the last byte.

PPSS identifies a PPS request or response and equals to "FF ".

Pps0 indicates whether the optional bytes pps1, pps2, and pps3 exist based on whether bb5, B6, and B7 are equal to 1. BB4 to B1. the shipping parameter T value is recommended as a protocol. B8 is reserved for future use and should be set to 0.

Pps1 allows IFD to recommend the values of F and D to the card. Encoded according to the same method as Ta (1). These values are located in FD ~ Fi and DD ~ Within the di range. If IFD does not send pps1, it is recommended to continue using FD and DD. ICC can either confirm two values by sending pps1 back (then these two values become FN and DN), or continue to use FD and DD without sending pps1 (then FN is set to 372, DN is set to 1 ).

Pps2 and pps3 will be retained for future use.

The value of PCK is as follows, so that the XOR operation result involving all the bytes PPSS to PCK (including PPSS and PCK) is 0.

 

 

3. Successful PPS exchange

If the PPS response accurately replies to the PPS request, the PPS exchange is successful. This is the most common situation. However, other situations may also occur.

When a PPS response is in one of the following circumstances, the PPS exchange is successful:

-- PPSS response = PPSS request;

-- Pps0 response:

Return b1-b4;

B5 should be returned or set to 0;

If B5 = 1, pps1 response = pps1 request;

If B5 = 0, the pps1 response does not exist, it means FD and DD should be used.

The return B6. or set it to 0;

If B6 = 1, pps2 response = pps2 request;

If B6 = 0, neither the pps2 response nor the pps2 request exists.

Return to B7 or set it to 0.

If B7 = 1, pps3 response = pps3 request;

If B7 = 0, neither the pps3 response nor the pps3 request exists.

Any other circumstances of PPS exchange should be interpreted as unsuccessful.