Digital Certificate Requirement

To implement digital signature cryptographic functions, a key pair of a private key and a public key is required. The key pair is stored in a digital certificate form. The Norwegian Tax Authority requires that the digital certificate format to be as shown below.

Format: x.509
Charset: UTF-8
Encoding: Base-64
Endianness: Little Endian
OAEP Padding: PKCS1 v1.5 padding
Private key size: 1024 bits
Hash Message Format: SHA-1

Digital Signature

Digital signature in our context here is the asymmetrically encrypted hash of the Transaction Data. Briefly, the digital signature is defined as:

<Transactiondatahash> = Sha-1(<Transactiondata>)
<Digitalsignature> = Rsa-1024(<Transactiondatahash >) Using The Private Key

Signing and Verification Process

Figure 30-13 Signing and Verification Process

Figure 30-14 Sample Signed and Verified Certificate

This figure shows the sample signed and verified certificate.

Digital Signature Trail

To preserve the integrity of transactions, the Norwegian Tax Authority mandates that the digital signing process should be chained, as shown below where the signature trail that SPMS would apply appears for its digital signing function.

Cruise Line Company A
- Ship AA
  - TransactionAA1
    - SignatureAA1
  - TransactionAA2
    - SignatureAA2 (from SignatureAA1)
  - TransactionAA3
    - SignatureAA3 (from SignatureAA2)
- Ship AB
  - TransactionAB1
    - SignatureAB1
  - TransactionAB2
    - SignatureAB2 (from SignatureAB1)
  - TransactionAB3
    - SignatureAB3 (from SignatureAB2)
Cruise Line Company B
- Ship BA
  - TransactionBA1
    - SignatureBA1
  - TransactionBA2
    - SignatureBA2 (from SignatureBA1)
  - TransactionBA3
    - SignatureBA3 (from SignatureBA2)
- Ship BB
  - TransactionBB1
    - SignatureBB1
  - TransactionBB2
    - SignatureBB2 (from SignatureBB1)
  - TransactionBB3
    - SignatureBB3 (from SignatureBB2)

Verifying Digital Signature

Table 30-11 Digital Certificate Elements and Descriptions

Element in SAF-T Cash Register	Description	Format and requirements	Examples
signature (previous)	Signature from previous receipt	Base-64 If no previous receipt the signature value must be set to “0” – number zero	signature_from_previous_receipt
transDate	Date at which the transaction was performed.	YYYY-MM-DD Do NOT use time zone or combined date and time format.	2014-01-24 2015-10-29
transTime	Time at which the transaction was performed.	hh:mm:ss Use ss=00 as default value if no information of seconds are available. Same as within the SAF-T export. Do NOT use time zone or combined date and time format.	23:59:59
nr	Transaction number. This must be a unique, sequential number within a journal. This will be the same as the number stated on the issued receipt	No leading or ending spaces.	123456789
transAmntIn	The amount involved in the transaction, including VAT.	Decimal Data Type: Numerical field with two decimals. Decimal separator “.” (dot). No thousand separators. No leading or ending spaces.	1250.00 -1250.00 0.00
transAmntEx	The amount involved in the transaction, excluding VAT.	Decimal Data Type:	1000.00 -1000.00
signature (current)	Signature of current receipt	Base-64 If no previous receipt the signature value must be set to “0” – number zero

Below are the steps to verify the digital signature.

Get Transaction Data from e-journal xml file.
Ensure that you have the public key in PEM format. You need this to verify the signature.
Save the transaction data in message.txt file.
Save the signature in signature.txt file.
Go to Windows search and type “git bash” to start the command line tool.

Extract the public key from the certificate.

$ openssl x509 -pubkey -noout -in <certificate_name> > pubkey.pem

Now, decode the base64 encoded signature and store it in “<signature_name>.txt” file.
```
$ cat signature.txt| base64 -d > <signature_name>.txt
```

Finally, verify the signature.

$ openssl dgst -<name> -verify pubkey.pem -signature <signature_name>.txt message.txt