DS smart card is a CPU card product developed by Philips. It was widely used by early chip manufacturers to develop and promote their COs. It is now like infineon (former Siemens semiconductor) and the former Philips semiconductor seldom promotes its cos, and most of the time it is focused on promoting its chips.
Phillips's DS Smart Card cos integrates the iso7816 and ETSI specifications (that is, SIM card specifications), and adopts a password verification method similar to SIM card in terms of security mechanisms, that is, access control permissions for files are obtained through password comparison.
The ds CPU card defines three basic access permissions: The issuer permission (0 to 3), the shared permission (0 and 1), and the cardholder permission (0 and 1 ). These access permissions are defined by the corresponding access permission area in the password unit. The corresponding passwords are respectively the issuer's password and the cardholder's password. The shared permissions can be obtained using the issuer's password or the cardholder's password. After correctly verifying the password, you can obtain one or more permissions based on the data bit set in the access permission area. Once a permission is obtained, the permission is retained until the card is powered off or the same password is incorrectly authenticated. The permissions obtained for each correct password authentication are accumulated.
There are 16 states in which you can set the permissions. 0 indicates that the authentication is always satisfied, that is, no authentication is required, and 15 indicates that the authentication is never satisfied, that is, no access is allowed. The remaining 14 states can correspond to different passwords or combinations of passwords for access control. The corresponding unlock password is also designed for each password. When the number of consecutive Incorrect verification passwords exceeds the specified number of times, the password will be locked and can only be unlocked after verification. The following table lists the combinations of access control permissions:
Access control number |
Required access control permissions |
Access control conditions |
0 |
Unavailable |
Always meet |
1 |
10 00 0000 (80 h) |
Cardholder permission 0 |
2 |
01 00 0000 (40 h) |
Cardholder permission 1 |
3 |
00 00 0000 (00 h) |
Never satisfied |
4 |
00 00 1000 (08 h) |
0 issuer Permissions |
5 |
00 00 0100 (04 H) |
Issuer permission 1 |
6 |
00 00 0010 (02 h) |
Issuer permission 2 |
7 |
00 00 0001 (01 H) |
Issuer permission 3 |
8 |
10 00 1000 (88 h) |
0 for the cardholder and 0 for the issuer |
9 |
01 00 1000 (48 h) |
Cardholder permission 1 and issuer permission 0 |
10 |
00 10 0000 (28 h) |
Share permission 0 |
11 |
00 01 0000 (10 h) |
Share permission 1 |
12 |
00 10 1000 (28 h) |
Share permission 0 and issuer permission 0 |
13 |
00 10 0100 (24 h) |
Share permission 0 and issuer permission 1 |
14 |
00 10 0010 (22 h) |
Share permission 0 and issuer permission 2 |
15 |
Unavailable |
Never satisfied |
In general, the cos of the ds cpu card is designed based on SIM card specifications, and the file management and operations also comply with SIM card standards, for example, in addition to reading and writing files, file access is also disabled and enabled. Files cannot be modified after they are disabled, determines whether the file is readable after being disabled based on the disabled or not specified during file creation.
The ds supports only one EF file type, that is, transparent binary files.
Dscard also has a certification technology that is said to apply for a patent, using desAlgorithmTo authenticate the data stored on the card, so as to determine whether the card content of a specific address that the terminal knows is correct. This authentication method is similar to the internal authentication stipulated in 7816, however, the Mechanism has its own definition, so it is also interesting. Almost no one in the most widely used CPU cards has used this mechanism.
This authentication mechanism can check whether the changed data is correct, read the ciphertext of the file content, and implement internal authentication with random numbers. In fact, the terminal should be able to know exactly the four bytes of data stored in a certain position in the card. In authentication, it is not a simple password comparison method, instead, random numbers and authentication responses are used for calculation and comparison.
authentication depends on the current EF file. Before authentication, the read permission on the file must be satisfied. The first step is to generate a temporary key, and the second step is to use the temporary key obtained in the first step to calculate the authentication data. First, the terminal sends 8 bytes of random data to the card. The card replaces the first two bytes with the ID of the current file, use this data to obtain the temporary key through the authentication key kc for des decryption. If you re-select the correct file, the temporary key originally calculated will be damaged. Then, the temporary key is used to perform des decryption on the 4-byte data of an address in the file and its corresponding two-byte addresses. For redundancy and 8-byte des computing needs, two bytes of data are duplicated, that is, the 8-byte data structure is: Data (4 bytes) + address (2 bytes) + address (2 bytes ). After the calculated 8-byte authentication data is transmitted to the terminal, the terminal can check whether the calculation result is correct to determine whether the authentication is successful.