Discrepancy between the FASCN format on real cards vs the test cards

[Michael Maz]

Team,

When decoding the 200-bit FASC-N of the test cards and available documentation, I am finding discrepancies in some of its encoding versus what is actually being observed on real PIV cards in use, specifically related to the Longitudinal Redundancy Character (LRC).

SP 800-73 and several other SP800 documents reference the "Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems, Version 2.2" (TIG SCEPACS) for the decoding method of the FASC-N.

The 200-bit FASC-N is encoded in BCD 4-Bit Decimal Format with Odd Parity, beginning with a start sentinel, data, end sentinel, and ending with the LRC.

Quick context from the docs: The FASC-N consists of 32 numeric characters of meaningful data. In addition, it contains a single numeric character called the Longitudinal Redundancy Check (LRC) that serves as a means by which a reader can mathematically validate its reading of the preceding data.

The value of each bit in the LRC character, excluding the parity bit, is defined such that the total number of one bits encoded in the corresponding bit location of all characters of the data message, including the start sentinel, field separators, data, end sentinel, and LRC character, shall be even. The LRC parity bit is for the LRC character itself and is calculated as described in the preceding paragraph.

TIG SCEPACS provides an example decode where we see the LRC is 7.

For all 16 of the test cards, the LRC is a number within 0-9 as expected. However, I have encountered 2 PIV/CAC cards in the field where the LRC was 01110, a value that is not in the decoding table. Using BCD, this to my understanding will decode to hex 14, but this does not satisfy the statement that the LRC is a single numeric character.

This is posing a problem because it does not allow for the full 200-bit FASC-N to be stored or decoded under the direction of TIG SCEPACS, and it is unknown if there are other values that could appear in the LRC that could cause unexpected behavior in applications. Does anyone know why this value is unexpectedly being encountered only in real cards and what it should decode to?

TIG SCEPACS was published in 2005 and is one of the oldest still referenced documents in the 201 related collection. Many of the implementations and concepts referenced in it have been fully deprecated. Are there any plans to create an updated revision of that document in the form of a NIST special publication?

Thank You, 
Michael Maz
m...@lokiani.com

[Douglas E Engert]

The LRC is calculated from the other characters so may be any value with parity.
In the example the 7 sentinel characters all have the ---x- bit set and only the single "9" 10010 has it set.
So the LRC would have the X as 0

If one of the "0" characters was an "8" 00010 or a "9" 10011  the LRC would be 11110 or 01101. (if I did the math correctly)

In other words  "/(LRC) that serves as a means by which a reader can mathematically validate its reading of the *preceding* data."

/I have some code to generate FASC-N, but not readily available.

On 8/6/2024 5:32 AM, Michael Maz wrote:
>
> Team,
>
> When decoding the 200-bit FASC-N of the test cards and available documentation, I am finding discrepancies in some of its encoding versus what is actually being observed on real PIV cards in use,
> specifically related to the Longitudinal Redundancy Character (LRC).
>
> SP 800-73 and several other SP800 documents reference the "Technical Implementation Guidance: Smart Card Enabled Physical Access Control Systems, Version 2.2" (TIG SCEPACS

> <https://www.idmanagement.gov/docs/pacs-tig-scepacs.pdf>) for the decoding method of the FASC-N.

>
> The 200-bit FASC-N is encoded in BCD 4-Bit Decimal Format with Odd Parity, beginning with a start sentinel, data, end sentinel, and ending with the LRC.
>

> *Quick context from the docs*: /The FASC-N consists of 32 numeric characters of meaningful data. In addition, it contains a single numeric character called the Longitudinal Redundancy Check (LRC)
> that serves as a means by which a reader can mathematically validate its reading of the preceding data./
>
> /The value of each bit in the LRC character, excluding the parity bit, is defined such that the total number of one bits encoded in the corresponding bit location of all characters of the data

> message, including the start sentinel, field separators, data, end sentinel, and LRC character, shall be even. The LRC parity bit is for the LRC character itself and is calculated as described in

> the preceding paragraph./

>
> TIG SCEPACS provides an example decode where we see the LRC is 7.
>

> image.png
>
> For all 16 of the test cards, the LRC is a number within 0-9 as expected. However, I have encountered 2 PIV/CAC cards in the field where the LRC was 01110, a value that is not in the decoding table.

> Using BCD, this to my understanding will decode to hex 14, but this does not satisfy the statement that /the LRC is a single numeric character/.

>
> This is posing a problem because it does not allow for the full 200-bit FASC-N to be stored or decoded under the direction of TIG SCEPACS, and it is unknown if there are other values that could
> appear in the LRC that could cause unexpected behavior in applications. Does anyone know why this value is unexpectedly being encountered only in real cards and what it should decode to?
>
> TIG SCEPACS was published in 2005 and is one of the oldest still referenced documents in the 201 related collection. Many of the implementations and concepts referenced in it have been fully
> deprecated. Are there any plans to create an updated revision of that document in the form of a NIST special publication?
>
> Thank You,
> Michael Maz
> m...@lokiani.com
>
>
>
>
>
>

> --
> To unsubscribe from this group, send email to piv-test-card...@list.nist.gov
> Visit this group at https://groups.google.com/a/list.nist.gov/d/forum/piv-test-cards
> To unsubscribe from this group and stop receiving emails from it, send an email to piv-test-card...@list.nist.gov.

--

Douglas E. Engert <DEEn...@gmail.com>

[Michael Maz]

Douglas and group,

I think I understand now, but correct me if I am wrong. 

The LRC bits can be any 5 bits, and are not required to be decoded into a numeric character like the rest of the data. It seems I made this assumption from what I am assuming now is a typo in section 5.4 paragraph 5 of TIG SCEPACS that says "In addition, it contains a single numeric character called the Longitudinal Redundancy Check (LRC)..." but should instead say something like "In addition, it contains a value that takes up the same number of bits as a single numeric character called the Longitudinal Redundancy Check (LRC)..." and that the LRC is shown as a number in the example. In terms of the variance between the test cards it sounds like It was just luck the 16 cards all have FASCNs that also decode to a number 0-9. At the very least, applications that are handling the full 200 bits don't have to care about representing the LRC with the other data elements, as it can be computed backwards even if it was unknown by a user entering the decoded data as input.

Thank you Douglas. It would be interesting to see your FASCN code, but no need to dig it up if it's a high effort for you.

Kind regards,

Michael Maz
m...@lokiani.com

[David A. Cooper]

There's nothing wrong with interpreting the LRC as a single numeric character, just not as a decimal character.

I am not seeing that all 16 test cards have FASC-N's with LRCs in the 0-9 range. On card 4 of the version 2 test cards the FASC-N is D650185B3CCE6D9C905325A1625A10AA09C4378486501843EB. So, the last five bits are 01011, which would correspond to a value of 10 (a in hexadecimal). For card 10, I get an LRC of 01110, which corresponds to a value of 14 (e in hexadecimal).

A user entering the decoded data as input could just enter the 32 decimal data digits, and then the start and end sentinels, field separators, LRC, and parity bits could be computed.

Section 5 of https://www.idmanagement.gov/docs/fips201ep-frtc-pacs.pdf discusses encoding the FASC-N in 128 bits (4 bits for each of the 32 decimal data values).

[Michael Maz]

David and group,

Thanks, it appears that you are correct and there were samples of LRCs like this in the test cards after all. When I was conducting this test a colleague of mine had borrowed those two cards and I had assumed I was working with the entire stack. 

From the documents I have read such far, I thought that you cannot use values outside of the ones listed in Figure 7 (the precomputed decode table graphic) of TIG SCEPACS as there is emphasis throughout the document that you can only use BCD digits, but I suppose the LRC is the exception. 

Fips 201 ep-frtc-pacs is a document I have not read yet. Appreciate you sharing that link as it is very useful and this has fully clarified my concerns.

Kind Regards,
Michael Maz
m...@lokiani.com

[Douglas E Engert]

The sentinel 5 codes are the A-F of the 16 bits.
The LRC has a parity bit for each of the bits in the data.  Probably goes back to 60 years  before ASCI was invented  and using serial comunication.
I go back to using 7 track tapes and paper tape days.