Happy New Year: Analog Sensor & IOT Relay Code

Happy New Year! To start the year out right, I am sharing my Arduino code for enabling/disabling power using a Digital Loggers' AC/DC Control Relay and a Funduino Keyes photosensitive analog sensor. Tweak the if/else numbers to suit your environment or swap out the module for another sensor. Next year, you won't even have to switch on your Christmas tree!

https://github.com/hackingsdn/ArduinoIOT

PCI Essentials: Credit Card Numbers Explained

The issuance of credit card numbers are defined by the ISO/IEC 7812-1 numbering system, a standard that associates a card issuing institution (Visa, MasterCard, American Express) to a block of six digit numbers. Only one six-digit Issuer Identification Number (IIN), actually more akin to a prefix, is assigned to each card issuer by the American National Standards Institute (ANSI). The most notable of IINs can be recognized by their first two digits:

• American Express: 34xx and 37xx
• JCB: 35xx
• Visa: 4xxx
• Mastercard: 50xx to 55xx
• Discover: 64xx and 65xx

As stated the IIN accounts for the first six digits of the 16-19 digit credit card number, including the Card Verification Validation (CVV) code. The next seven to 18 digits represent the customer's account number; whereas, digits 16 to 19 are reserved for the CVV. Credit card numbers are validated using the MOD 10 algorithm. "The MOD 10 algorithm is a checksum (detection of errors) formula which is the common name for the Luhn algorithm." There are also a plethora of standards that are associated with magnetic based cards:

• IEC 7180 (format ID-1) defines the credit card dimensions.
• IEC 7812 defines the first digit of the IIN as a "major industry identifier":
• 0 - ISO/TC 68 and other industry assignments
• 1 - Airlines
• 2 - Airlines, financial and other future industry assignments
• 3 - Travel and entertainment
• 4 - Banking and financial
• 5 - Banking and financial
• 6 - Merchandising and banking/financial
• IEC 7813 mandates physical card characteristics and magnetic track data structures

If we look at an example credit card number provided by PayPal to test credit card numbers, we can easily parse it given the above information. For example, credit card number: 6011000990139424

• IIN digits: 601100 (Discover)
• Customer Account Number digits: 0990139424
• CVV: Omitted by Paypal to prevent usage.

Card swipers read data from the credit card's magnetic strip and display it based on the desired "track" number. It should be noted that hotel room keys also use this same format; although, the track type is subject to the implementation. It is easy to discern the first track based on the initial character or sentinel start. Track 1 begins with a start sentinel ASCII percent character "%" followed by the letter "B" denoting its format code. It is followed by the Primary account number (e.g., credit card digits) with each additional field separated by the "^" character. The CVV may also be separated from the PAN and is trailed by the end sentinel or "?" question mark. An example of track 1 data is as follows:

%B6011785948493759^DOE/JOHN L                ^^^0000000      00998000000?

Track 2 data similarly initiates with a start sentinel (";") followed by the PAN and a separator of an equal sign ("="). Like Track 1 data, it's successor also has an end sentinel question mark character. Track 3 specifications for financial institution cards is outside the scope of this post.

Card Reading Tips:

• The following regext will parse track 1 data into its six groups: 
• ^%([A-Z])([0-9]{1,19})\^([^\^]{2,26})\^([0-9]{4}|\^)([0-9]{3}|\^)([^\?]+)\?$
• For reading track 1 and 2 data, I have had some success with the following card swiper:
• "MagTek 21040108 Triple Track Magnetic Stripe Swipe Card Reader with USB Keyboard Emulation and 6' Cable, 50 in/s Swipe Speed, Black"
• Echo output to file on Windows OS 
• C:\ TYPE CON > output.txt
• Press Ctrl + C to exit.
• Echo output to file on Linux OS
• $ cat 2>&1 | tee outfile

References: 

• http://www.getcreditcardnumbers.com/
• http://publicaa.ansi.org/sites/apdl/Documents/Other%20Services/Registration%20Programs/Important-Info.pdf
• https://www.paypalobjects.com/en_US/vhelp/paypalmanager_help/credit_card_numbers.htm
• https://en.wikipedia.org/wiki/ISO/IEC_7180
• https://en.wikipedia.org/wiki/ISO/IEC_7812
• https://en.wikipedia.org/wiki/ISO/IEC_7813
• https://en.wikipedia.org/wiki/ISO/IEC_4909
• https://en.wikipedia.org/wiki/ISO/IEC_7813

ICS Essentials: IEEE-1588 Precise Time Protocol (PTP)

IEC 61850-compliant substations require ~1 microsecond timing accuracy. The goal of Precise Time Protocol (PTP) is to accommodate this demand; however, PTP accuracy is dependent upon hardware, such as the processor type - physical or virtual CPU. Some vendors, most notably Belden (i.e., Hirschmann), has had success with integrating PTP on Linux, VxWorks and Windows platforms. For the hobbyist, you can simply tweak the ACPI Linux kernel's boot parameters to reduce the amount of drift between the internal clock and the PTPd daemon:

• Edit the Linux Grub configuration file: $ sudo vi /etc/default/grub
• Add the following ACPI Linux kernel parameter to the file: nohz=off
• Update Grub: $ sudo update-grub
• I recommend a system restart.

Not all devices support PTP due to their chosen hardware CPU implementation. Additionally, not all switch expansion modules support PTP, e.g. Cisco IE 3000 switch's expansion modules. This highlights the need for a proper understanding of the device's supported capabilities as the default PTP configuration may need adjustment. For example, the IE 3000 has a default delay request interval of 32 seconds and the default sync interval is 1 second. Obviously, this could be a deal breaker should your field devices have more granular time requirements. Note: Cisco's IE 3000's PTP clock properties can be enumerated via the IOS "show ptp clock" command.

Currently, there are two standards of PTP available: IEEE1588 (PTPv1 circa 2002) and IEEE1588-2008 (PTPv2). If version specificity was not enough, there are different profiles - Telecom, Power, and others:

• G.8265.1 (Telecom & Frequency Profile)
• G.8275.1 (Time & Phase Profile)
• G.8275.2 (Time and Phase Profile with partial support from the network)
• Furthermore, several recommendations exist for wireless applications in the form of G.8265.x

PTP can be encapsulated within IPv4, IPv6, Ethernet, and even IPSEC. There is a cost to the latter that we will discuss in a subsequent post. PTP is configurable in either unicast (frequency profile only) or multicast (over UDP). Multicast addresses are specific to the PTP version. For example, multicast PTP uses the following IPv4 address schemes:

• 224.0.0.107/32 Mcast_PTP_v2
• 224.0.1.129/32 Mcast_PTP_v2_messages. This multicast IPv4 address has an IPv6 companion -  FF0x:0:0:0:0:0:0:181 for Ipv6, where 'x' can be a value between 0x0 and 0xF. Reference IEEE1588, Annex E, Section E.3.
• 224.0.1.130/32 Mcast_PTP_v1_messages
• 224.0.1.131/32 Mcast_PTP_v1_messages
• 224.0.1.132/32 Mcast_PTP_v1_messages

The above multicast addresses should not be confused with mDNS (224.0.0.251/32) or multicast NTP (224.0.1.1/32). PTPv2 is not backwards compatible with version one.

To minimize inaccuracies, PTP's algorithm supports "best master clock" options and calculates the slave's offset and delay correct time via the below sequence:

1. The master clock sends a SYNC packet containing the grandmasters annotated real-time.
2. A second packet can be sent by the master (subject to its hardware capabilities) to facilitate the slave's time synchronization to the master; thus, it can determine the delay of transmission from the master. This step is referred to as a "two step process" and is optional per implementation. Unlike NTP, PTP sends sync and follow-up messages at a minimum of 1 packet/16 seconds to a maximum of 128 packets per second (pps).
3. The slave transmits a delay request to the master in order to define the latency for its return path.
4. In return, the master sends a delay response to the slave. Now, both systems know the round-trip time (RTT) propagation delay. The slave will divide the total (RTT) by two and adds the result to its current time. Delay requests and responses are also transmitted between 1 packet/16 seconds to 128 pps.
5. Both of the clocks are in sync and the master will instruct the slave to increment or decrement time to ensure accuracy.

This negotiation can be viewed in Wireshark - https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=ptpv2.pcap

The IEEE-1588 Grand Master serves as the primary reference time clock (PRTC) and it often receives its timing via GPS. It is uncommon to find Grand Masters within a substation as its typically, an edge device. Other architectures may require a Boundary Clock (BC) or multiple BCs  to forward PTP timing information to field devices or relay across the topology without delaying time as packets may be queued. These services can be found within some vendors' networking devices. Lastly, we have the clients that are referred to as slaves or "Other Clocks (OC)".

It is trivial to setup PTP within your lab; although, accuracy will drift in this virtual setup.

• Install the Linux PTP daemon on at least two systems (grand master and slave) via APT: $ sudo apt-get -y install ptpd
• Start the PTP daemon on the grand master VM: $ sudo ptpd -CPWjb eth0
• Start the PTP daemon on the slave VM: $ sudo ptpd -CPjb eth0
• In this example, the PTP slave will be listening on UDP ports 319 and 320.

In a subsequent post, we will discuss the attack surface of PTP. Stay tuned!

References:
https://www.youtube.com/watch?v=yw-gd01aOYg
http://tf.nist.gov/seminars/WSTS/PDFs/3-4-IDT_Rodrigues-IEEE%201588-profiles%20at%20ITU-T%20.pdf
http://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie3000/software/release/12-2_46_se1/configuration/guide/scg1/swptp.html
https://splash.riverbed.com/thread/8141
http://ubuntuforums.org/showthread.php?t=1366354
https://wiki.wireshark.org/Protocols/ptp
https://www.belden.com/docs/upload/Precision_Clock_Synchronization_WP.pdf