RFID and Raspberry PI

SainSmart RFID-RC522 & Pi

My first blog about some hardware hacking I am looking at, this article describes connecting the SainSmart RFID-RC522 module with the Raspberry PI. It refers to work that others have done, please see the references at the end of the blog for the sources of information I have used. However by collecting together these sources and my own additions, this will help others.

The SainSmart RFID-RC522 module works with the Mifare RFID tags and uses the RC522 chip. SainSmart have provided a module that can be used as a RFID Reader Card Proximity Module. The module uses the SPI bus to communicate with a controller. For those using a Raspberry PI it is imoprtant to note module uses 3.3v and is compatible with the voltage inputs on the Raspberry PI.

The Serial Peripheral Interface bus (SPI) bus is a synchronous serial data link which the Raspberry PI supports through its GPIO, the PI supports two slave devices using the CE (Chip enable) pins.

Enable the SPI on the Raspberry PI

As the SPI is not enabled by default you will need to edit the raspi-blacklsit.conf in order to enable the SPI interface; this has been blacklisted as most users are not interested in it according to the comment in the file. There are only two devices in the file, the SPI and I2C.

sudo vi /etc/modprobe.d/raspi-blacklist.conf

Add '#' in front of the line spi-bcm2708 to comment it out of the blacklist. Save the file, and you will need to reboot the Raspberry PI, after which the lsmod command should show the spi device (spi_bcm2708) enabled.

Connection Diagram

Connecting the module to the PI is reasonably straight forward, as the wiring diagram shows, my breadboard set is also pictured.

SPI Code

To use the module from Python, need to load a SPI wrapper, however we need to install ‘python-dev’ to enable us to install the SPI wrapper.

To install ‘python-dev’ :

sudo apt-get install python-dev

In order to read data from the SPI bus in Python we need a set of routines, a suitable set is SPI-Py, available form github.

To do the install, clone the SPI-Py git repository. This is the source code for the SPI python library we’ll be using.

git clone https://github.com/lthiery/SPI-Py.git

Install the SPI-Py module by typing

cd SPI-Py
sudo python setup.py install

Sample Program

In order to test the module out they is a sample code which is a Python port of the example code for the NFC module MF522-AN and provides a small class object to interface with Moduleon the Raspberry Pi.

This is a Python port of the example code for the NFC module MF522-AN

sudo python MFRC522.py

If everything I working you should be able to read the tags that came with the SainSmart module.

Resources

http://www.sainsmart.com/sainsmart-mifare-rc522-card-read-antenna-rf-rfid-reader-ic-card-proximity-module.html
https://github.com/lthiery/SPI-Py
https://github.com/mxgxw/MFRC522-python

PCI DSS and strong encryption

The PCI Security Standards council have updated (January 2014) their glossary to version 3  https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_Final_v3.pdf this includes an update to their definition of strong cryptography, increasing the key lengths on some encryption protocols. They are now saying examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum triple-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher).

Changes include

• Triple DES key length being increased from minimum double to triple length
• RSA key lengths being increased from 1024 bits double to 2048 bits
• ElGamal key lengths being increased from 1024 bits double to 2048 bits

The change to RSA key lengths bring the acceptable minimum key length to that recommended by the Certification Authority/Browser (CA/B) Forum and the National Institute of Standards and Technology who have determined that any key length below 2048-bit is no longer strong enough for SSL certificates.

This will effect merchants and service providers, they will need to examine their cryptographic systems in particular SSL certs on https and increase key lengths or purchase new certs to meet requirements

Compliance to the PCI DSS Standard

In light of the recently reported breaches, in particular those of Target and Neiman-Marcus where the likely attack vector was memory scraping malware in the Point of Sales (POS) equipment there has been discussion in various forums over compliance to the Payment Card Industry (PCI) Data Security Standard (DSS), security provided and the use certified components.

The PCI DSS

To some, when they see a merchant or service provider is complaint to the PCI DSS, they assume it will be secure and is protecting cardholder data, to a degree that is true. The PCI Security Standard Council (SSC) say the "PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data." and "PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations." they don't claim it makes entities secure but provides a minimal level of security for card holder data to reduce risk.

The advantage of the PCI DSS is that it gives a baseline level for security that will reduce card fraud and benefit cardholders, merchants, service providers, card issuers and payment brands. It is feasible that a merchant or service provider may have good information security practices and be protecting cardholder data without looking at the requirements of the standard, but the PCI DSS does provide a measurable way of identifying controls that will protect cardholder data.

Measurement of the controls is done through auditing against the requirements. The annual audits carried out to verify compliance to the standard are a snapshot in time, that merchant or service provider have implemented the requirements and there is evidence available that controls have been operating correctly since the previous audit. Audits are conducted by external qualified assessors for the bigger merchants and service providers (in terms of payment transactions) or can be done by qualified internal assessors or by employees of the merchant or service provider as a self-assessment questionnaire for the lower levels of transactions. The auditing process may not be perfect, especially when self assessment is being done but it does get even small merchants to think about the requirements of the PCI DSS.

Certified devices and applications

Merchants are unlikely to develop their own systems for POS and payment processing, but use commercial products. The PCI SSC, in addition to the DSS, has issued a number of other standard covering card data processing applications and payment transactions devices (Chip n pin terminals, PED, PDQ etc).  For example the PCI SSC have issued the Payment Application Data Security Standard (PA-DSS) which they say "Secure payment applications (certified to the PA-DSS), when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches leading to compromises of PAN, full track data, card verification codes and values (CAV2, CID, CVC2, CVV2), and PINs and PIN blocks, along with the damaging fraud resulting from these breaches."

These additional standard allow vendors to have their products (hardware and software) tested to prove they support the requirements of the PCI DSS and have them certified as prove of this. The intention of these standards is to help merchants and service providers meet the PCI DSS, by identifying components that can be used that will help meet the requirements of the PCI DSS. Auditors do not need to prove the payment terminal or payment application are correctly protecting card holder data as PCI SSC certified assessors have already verified the equipment.

In order for certified components being used to help merchants/service providers to meet the PCI DSS requirements they must be installed, configured and maintained to the vendors instructions. Part of the certification process for vendors is the production of the instructions.

For a merchant or service provider the important part of using certified components is that they MUST be installed to the vendor’s instructions to ensure that they do protect card holder data. An auditor of the merchant or service provider, whether there are a (qualified Security Assessor) QSA, Internal Security Assessor (ISA) or an employee, has to verify that the certified components have been deployed as per the vendor’s instruction, and NOT that they just are listed on the SSC website and ensuring the correct certified software, firmware and hardware is in place.

Conclusion

It is important for merchants and service providers to understand that being compliant is not the same as being secure, more can be done to secure card holder that the controls to meet the requirements of the PCI DSS, however the PCI DSS is the minimum acceptable level of security controls. The use of certified applications and devices is an important step to meeting compliance BUT those components need to installed, configured and maintained to the vendors instructions for that component to offer the level of protection the certification implies. For those conducting PCI DSS auditors, whether for a RoC or an SAQ, they need to be aware it is not just the component is listed or that the component is of the correct revision for the listing that is important but they ensure the component is being installed, maintained and used as per the vendor’s instructions.