FUJ00124015
FUJ00124015
Exkibrt
oO Horizon Online Data Integrity for Post Office Lid Quy I 2
FU ITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
Document Title: Horizon Online Data integrity for Post Office Ltd
Document Reference:
Release: NIA
Abstract: This document describes the measures thal are built into Horizon
Online to ensure data integrity.
Document Status: Draft
Author & Dept: Gareth I Jenkins
External Distribution:
Security Risk YES. security risks have been assessed, see section 0.10 for
Assessment Confirmed — “ta!
FUJIPSU RESTRICTED - COMMERCIATIN
PIOENCE
Uncontroiied if Printed or Distributed
FUJ00124015
FUJ00124015
8) Horizon Online Data integrity for Post Office Ltd
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
0 Document Contro!
0.1 Table of contents
0 DOCUMENT CONTROL
0.1 Table of contents
0.2 Figures and Tables..
0.2.1 Table of Figures
0.2.2 Table of Tables
0.3 Document History...
04 Associated Documents (internal & External
0.5 Abbreviations.
0.6 Glossary...
0.7 Changes Expected .
08 Accuracy ....
0.9 Security Risk Assessment
4 PURPOSE
2 HORIZON ONLINE DATA INTEGRITY
2.4 Overview of Normal Operation.
2.2 Detail of Normal Processing
2.3 Error Scenarios.
23.4 Recoverable
23.2 Failures
233 Time Outs
2.34 Forced Log Out...
2.3.5 Terminal Failure
2.3.6 Recovery i
24 Database Characteristics ..
Transactions
3. AUDIT SYSTEM... 14
0.2 Figures and Tables
0.2.1 Table of Figures
Figure 1 ~ Primary message flows . . vo B
0.2.2 Table of Tables
None
Uncontrofied if Printed or Distributed
FUJ00124015
FUJ00124015
fae Horizon Online Data integrity for Past Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
0.3 Document History
Version No. Date Summary of Changes and Reason for issue Associated Change -
CPIPEAKJPPRR
Reference
I 0.46 92/04/2012 This is a new document i
0.4 Associated Documents (Internal & External)
Reference Vewion Date Tite Source
PGMDOM/TEM0001 I
(DO NOT REMOVE)
CARCIGEN/REP/O001 I OHING.
s Pest Office Ancout
nent Template
Dimensions
I Fujitsu Servi
I HNG- Docur
Glossary Dimensions
DESVAPPHL0/0020 Branch Database High Level Design mensions
UHNG-X HLD -
Dimensions
NENSIONS
XML Message Audit between Counter
and BAL/OSR
Unless a specific version is referred to above, reference should be made to the current approved
versions of the documents.
0.5 Abbreviations
Abbreviation Definition
AP-ADS I Automated Payments ~ Advanced Data Capture. A mechanism that allows Post
i Ltd to produce scripts for specific transaction processing
APS I Automat
.d bill Payments Service
BAL I Branch Access Layer. The component that handies the interface from the counter
and updated BRD!
Branch Detabe
I Data Reroncifiation Service. A syst
Financia! Inetitutions
reconcile transactions carrie
rancial Accounting Dis
clal Institution
as Horizon Onkne
ate sub-posimasters
Printed or Distrebutedt
Uncontrot
FUJ00124015
FUJ00124015
eo Horiz:
mn Online Data Integrity for Post Office Ltd
FU] ITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
Abbreviation Definition
RAC Real Application Cluster
Or
Request. Authorisation, Confirmation. The mechanism used for interfac
Financial institut
ations prot
a Cente.
TOP HP The standard commun
Counter and the
sing System
Transaction Proc
0.6 Glossary
See also document ARC/GEN/REP/0001
Tenn Definition
Back Offioe Adrministiative Functions carried out i 4 Post Office Lid Branch such as Remitting in
Cash ck
Basket I The set of transact
transactions asse
For exampie all the
d with a single Customer (including those used for Settiement)
n Agent, for example DVLA where
to customers on behaif of DVLA,
Client An organisation for which Post Office Lid acts a
Post Office Lid provides Motor Vehicle licens
Unique identifier for a Post Office Lid Branch
transaction:
fvioes oF to the
Vithdrawals.
iat represent the payment by the Customer for goods or
Out Pay transactions such as Cash
0.7 Changes Expected
I Review comments ete
0.8 Accuracy
the information contained in thi
such information, if acceols no fe
document is correct but, whilst every
ity for any loss (however caused)
0.9 Security Risk Assessment
No iden’
fied security risks.
Uncontrotted if Printed or Distributed
FUJ00124015
FUJ00124015
eo Horizon Online Data Integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
1 Purpose
This document is a technical description of the measures that are built into Horizon Onfine (also known
as HNG-X) to ensure data integrity and descriptions as to how those measures apply in each case
Note that this document only covers Horizon Online (HNG-X). It does not cover the original Horizon
system, which is specifically excluded from this exercise. There is a separate document covering the
original Riposte-based Horizon system
Section 2 describes the measures taken in the design of the Counter, Branch Access Layer (BAL) and
Branch Database (BRDB) to ensure integrity. Section 3 describes the audit systern used to preserve the
auditable messages sent from the counter to the Oata Centre for use in Litigation Support.
The scope of this paper is restricted to showing the Integrity of the Audit trail and that it accurately reflects.
the transactions entered at the counter
iCTED - COMMERCIAL IN Ref
INFIDENCE Version
Uncontroited if Printed or Distributed Date
Page No
“S Copyright Fujisu Sanices Lid 2012 FUUTSU RE
FUJ00124015
FUJ00124015
oo Horizon Online Data integnty for Post Office Ltd
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
2 Horizon Online Data Integrity
2.1 Overview of Normal Operation
Horizon Ontine is designed to store all data in an online database known as the Branch Database
(BRDB) This database is a highly resilient Oracle database implernented using Oracie Real Application
Cluster RAC (see also section 2.4). in particular no data concerning Business Transactions is retained at
the counter other than in the memory of the Counter Business Application.
Asti
Oeacts
write
BAL Message Audit Retrieval
Figure 1~ Primary message flows
Transactions are carried out locally on the Horizon Onime counters and a Basket is built up during 2
Customer Session. Each transaction will result in a Basket Entry consisting of one or more Accounting
Lines, At the end of a Customer Session when the Gasket has been completed and all Settlernent tems
(or Tender ines) have been processed and added into the Basket as further Accounting Lines, such that
the totai value of the Basket is zera, the entire Basket is sent to the Data Centre as a BAL Message
where the Branch Access Layer (BAL) processes the message and ail the Accounting Lines are recorded
and committed to the BRDB as part of a single Oracle Commit. This means that either all the
transactions within a Basket are successfully written or none of them are. Once the Accounting Lines
have been successfully committed a response is returned to the counter indicating this success and this
then allows any receipts to be printed. The Basket is deemed to be fully completed once all relevant
receipis have been successfully ed. Note that if there are no receipts to be printed, then the screen
is updated to show the top level menu indicating successful completion of the previous Basket
The Oracle Commit also inckdes an Audit of the data orginally transmitted from the counter to the
BROB This data is digitally signed at the counter using a key generated as part of the Log On pro:
the identifier of the last successfully
‘fn order to support recovery as described in set
i However this is nol classed as Business
compieted Basket is recorded on the Hard disk at the counter
FURPSOU RES
Uncontrolled if Printed or Distributed
FUJ00124015
FUJ00124015
oO Horizon Online Data Integrity for Post Office Ltd
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
It is this audit record that is used to provide the extract of transactions used for Litigation support.
Section 3 describes how this audit record is managed after tis committed to BRDB.
The audit record may also include application events that have been accumulate at the counte
the last auditable message was sent to the Date Centre. Al major activities that affect the Br
have an audit of the data sent from the counter to the Data Centre included in the audit log. Such
activities include:
* Leg On/ Log OF of Users at the counter
* Creation / modification of User Accounts (including change of password)
« Atlaching Users to Stock Units
» Balancing @ Stock Unit
* Producing the Branch Trading Statement.
Each Audit record includes the following identification
* Branch identifier (Le. FAD Code)
* Counter identifier
* Sequence Number {known as a Journal Sequence Number or jsn)
* Counter timestamp
Within any counter (Le. for a given Branch id / Counter id combination), the jsr will always increase by
exactly one for each successive audit record. This enabies a check to be made that there are no records
missing from the audit trail when they are retrieved
The transactions in a basket are constructed using the principle of doubie-entry bookkeeping. This
means that in addition te the Accounting Lines that relate to the actual business transactions. separate
Accounting Lines are also generated for the tender items (such as Cash. Cheques or Credit / Debit
Cards}, resulting in the total value of all Accounting Lines in a Basket adding up te zero. When the
contents of a Basket are written to BRDB a check is made that the net value of ail the accounting lines is
indeed zero and should it not be, then an alert is raised and the basket is discarded and an error
response returned to the counter.
Pore th
his vould only hap,
che
Baskets are also built up during Back Office Sessions and such Back Office baskets are handied in 2
similar way to Customer Baskets.
2.2 Detail of Normal Processing
The purpose of this section is to expand on the summary in Section 2 1 and identify other documents
where more detail of the various steps are covered.
As outl
ed in section 2.1 above, the following is the key behaviour of the handing of a Basket
Each Business transaction will
Ihe counter and the value of which is
transactio
nemory of
41. The Clerk carries out one or more busin
construct 2 Basket Entry which js heid in the
visible on the screen
ts either the Fast
Wher ail the transactions for a customer have been cornpieted, the clerk sei
Selle functions on the screen
Cash or
Uneontrolied if Printed or Distributed
FUJ00124015
FUJ00124015
Horizon Online Data Integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
obit then etth
a wll? resale in ose
a Selecting Fast Cash results in the system calculating the amount to required fo take the
total value of the transactions in the basket to zero and constructs a Basket Entry for the
Cash Product for this amount and adds it into the Basket. By definition, the total value of
the basket at this point will be zero
b. Selecting Settle results in the system displaying a menu of permissible settlement
optons. The allowable settlement options are configurable and depend on various
Business Rules, however are likely to include the follewing
Cash
This allows a specific amount of cash to be entered (which may or may not be
the full amount), It will fake a sign based on attempting to move the Basket total
nearer to zero.
A corresponding Basket Entry is created and added to the in memory and
On-screen basket display with an updated total.
ho Cheque
This allows a specific amount for a Cheque to be entered (which may or may not
be the full amount}. its sign will always reflect the fact that a cheque is payable
to Past Office Ltd (other than for Reversals).
A corresponding Basket Entry is created and added to the in memory and
On-screen basket display with an updated total,
Up and PIN
This allows Chip and PIN transaction to be processed. The amount to be take
is entered, but defaults fo the maximum amount allowable by business 1
owhich may or may not be the full amount). [ts sign will always reflect the fact
that a payment is being made to Post Office Ltd (other than for Reversals}
His of the Busin EVAR Fert
1 Imegeity of the system.
A corresponding Basket Entry is created and added to the in memory anc
On- n basket display with an updated total,
iv Swipe
This wS magnetic swipe payment card to be processed Note thal if the
Magnetic stripe indicates that the card is a Chip and PIN card then the
transaction will be abaridoned at this point: The amount to be taken is entered
but defaults to the maximum amount allowable by business rules (which may or
may not be the full araount). its will always reflect the fact that a payment is
being made to Post Office Ltd (of than for Reversals),
On-sereen basket display with an updated total
v Fast Cheque
This allows Cheque transaction to be processed However in ¢
system calculates the amount required to take the total value of the
in the basket to zero and constructs a Basket Entry for the Che:
© Copyright F
Uncontrolled if Printed or Distributed
ices id cote PUJNSU RESTA
CONT
FUJ00124015
FUJ00124015
Horizon Online Data integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
this amount and adds # into the Basket. By definition, the total value of the
basket at this point will be zero
vi Fast Cash
This is the equivalent of the Fast Cash Button described at point a above
c The User is then able to select any of the available options and add appropriate
settlement items into the In memory and On-screen basket as descried. Should the
Total value of the Basket not be zero after processing the settlement transaction. the
settlement menu is re-displayed allowing further settlement transactions to be selected
until the net value of the Basket becomes zero
3. Once the Basket Total becomes zero, a message is constructed to send the entire basket
content fo the BAL. The structure of the message sent is defined in [DES/APP/AIS/0018]. A new
connection is established to the BAL in order to send this message. The message sent is
defined as being an auditable message and so will include a jsn. It may also pick up any
outstanding Audit Events and Statistical data that have been accumulated at the counter since
the last auditable message was sent from the counter to the BAL. This message will be signed
by the counter using a Digital Signature constructed using a key that has been generated as part
of the Log On process. This Digital Signature is sent as part of the message to the BAL.
4. When the BAL receives the message it detects that there is an associated jsn. This means that
the Audit Filter is mvoked which results in the entire data sent from the counter being added to
the BRDB table BROB_RX_MESSAGE_JOURNAL.
5. The BAL then processes the message and updates other tables in BRDB.
if all these updates are successful, then the BAL invokes a COMMIT to Oracle on BRDB which
will commit ail the changes at steps 4 and 5. Shouki there be any failure, then the BAL will issue
an Oracle ROLLBACK which results in none of the changes in steps 4 and § being saved and it
is then as if the interaction from the counter didn't take place. in either case a suitable response
is returned to the counter and the connection tot the counter is closed.
7. When the counter has sent the message to the BAL (at step 3), it waits for a Response. There
are 3 possible responses that can occur:
@. The BAL update was successful (this is the normal case)
b. There was e failure from the BAL
c. No response is received within a configurable timeout period (usually 20 seconds)
The first case is normal The last 2 cases are considered to be Error Scenarios and are
considered further in section 2.3, but are considered to be out of scope of the normal processing.
8. When the response is received, any receipts required are printed and then the in-memory and
On-screen baskets are cleared and the screen is updated fo the “Home” screen ready for a new
Basket to be started.
Overnight. the content of the table BRDB_RX_MESSAGE_ JOURNAL is copied to a set of serial files and
passed to the Audit system. There is more information on this audit process in section 3 of this
document.
2.3 Error Scenarios
2.3.4 Recoverable Transactions
Simplistically # could be assumed that ¢ @ Basket fads to commit then the content
be discanied
i basket can just
FOOTSU RESTRIC
CONFIDE?
MMERCIAL IN Re
ve
Uncontrolied if Printed or Distributed
FUJ00124015
FUJ00124015
oO Horizon Online Data Integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
‘This is similar to the normal model presented with on-line shopping, in that # your browser fails after
trying fo commit ie basket, you are uncertain as to whether your purchase hes been processed or not
You then need to carry out some other activity (@.g phone the provider or check your Credit Card
account the next dey} befere knowing whether or not to re-attempt the transaction
However this is not really appropriate in a Post Office environment For mary Wansactions it can be
assumed that the Basket has failed to commit and so the transactions in the basket are discarded and
they can be re-attermpted at some later date. However in some cases this is not appropriate since the
Transaction may have had an impact cn some extemal system. An example of this is a Banking Cash
Withdrawal. In this case the Bank has been informed of the Transaction during the processing of the
Banking Transaction and has removed the funds from the Customers account. Therefore it is important
that this transaction is completed. Such transactions are considered to be Recoverable Transactions
if @ transaction is to be Recoverabie. then information about that transaction is recorded in the BRDB
when the transaction js first initiated (and before the transaction is sent to the Ft) allowing the transaction
to be recovered should there be a failure. Note that this recovery information is not audited
There
* Ail Banking transactions
many types of Recoverable Transaction
« All Credit / Debit Card transactions
+ All
-Top up transactions
« All Reversals
* Selected AP-ADC transactions (as defined in the transaction script)
2.3.2 Failures
Any failures in committing Auditable activities at the Data Centre will result in an error response being
returned to the counter. Such an error response will be displayed to the User, thus informing them of the
sation The next action then depends upon the Auditable activity
» ff it relates to @ basket settiement where the basket that contains 1 or more Recoverable
Transactions, then a Forced Log Out is initiated and the normai Recovery process will lidy things
up
* if % relates to a basket settlement where the basket doesn't contain any Recoverable
Transactions, then the content of the basket is discarded end the User is returned to the Menu to
continue working
« If # relates to a non-basket activity.
Menu to continue working
hen activity is abandoned and the User is returned to the
in all cases the User is informed of what is happening
Such failures will not be visible in the transaction audit, but may be visible in the system Event Log
2.3.3 Time Outs
Should there be no response from the Data Centre following an attempted commit of an auditable act vity
within @ timeout period (currently set {9 30 seconds), an automatic retry is invoked This sends identical
dusiness daia io the Data Centre where a check is made to see if # é
committed to BRDE.
» If t has been committed means that the bul the
response did not reach the counter in trae Therefore i g the
BRDB and a Success response is returned to the
FURS
ATE GISG Services
Uncontrolled if Printed or Distributed
FUJ00124015
FUJ00124015
oO Horizon Online Data Integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
« lft has not been committed, then the original activity either didn't re: ie Data Centre, or it
failed to be proc in ether case it is safe to re-process the data and the appropriate
response is returned ic the counter after the data has been processed which wil be handled as if
if was from the original request. Note that re-processing the data will include recorling an audit
of the data if the reprocessing is successful
Should the retry also timeout, then the User is prompted and asked whether they wish to Retry or Cancel
the Activity
+ Selecting Retry results in the Activity being retied once more as described above. If this also
times out, then a further automatic retry is attempted and i this is stil unsuccessful, then the
User is again prompted as to whether to Retry or Cancel. This cycle then contiriues until either
there is success, or the User finally gives up and selects Cancel
* Selecting Cancel results in a Forced Log Out being invoked.
Such time-outs and any retries will not be visible in the transaction audit, but may be visible in the system
Event Log.
2.3.4 Forced Log Out
Continual failures to Update the Database at the Data Centre mean that it is not clear at the counter
whether or not the database accurately reflects the situation in the Branch. Therefore the safest thing is
to force a Log Off at the counter and ensure that when communications are re-established, that the
Recovery process is invoked to reconcile the counter view with thal on BRDB.
if there is a basket currently being processed. then a special Disconnected Session Receipt will be
produced showing which transactions have been discarded and which are to be recovered making it clear
what money needs to be exchanged with the Customer.
2.3.5 Terminal Failure
Clearly a counter terminal can fail at any time However the situation is not very different frorn that where
8 failure to contact the Data Centre has occurred as described above. Therefore the behaviour of the
User needs to be as follows
1. Work out the value of any Recoverable Transactions (there ought to be printed receipts
associated with all of these)
2. From this work out what is owed to, or due from the customer
3. Consider whether any Credit / Debit Card payments may have been successful
4. From this work out any cash due to / from the customer.
5. White out any necessary receipts by hand
6 Keep 2 record of exactly what happened to be used at Recovery time.
Clearly in this case the system is unable to assist the User in guiding them as to what to do.
2.3.6 Recovery
Recow
has fa
terminal
until the
ion
'y after a fail
ad and ne
Ai every Log On a check is made in the Central Database to see if any Recovery is required. The
following checks are carned out
© Copyngat u Services Lid 2042 FUJITSU RESTRICTED - COMMERCIAL IN Ref
CONFIDENCE Version:
Uncontroifed if Printed or Distributed Cate
FUJ00124015
FUJ00124015
wo Horizon Online Data Integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
1. is there any outstanding Recovery Data associated with this terminal?
if so return the outstanding Recovery Data te the counter so that the Wansactions can be
recovered using Rollforward Recovery
Did the fast session carried out on this terminal have a tidy Log O#?
N
if not, return details of the last Basket (if any) that was successfully written from the last Log On
session te the counter so that further recovery checks can be made
Otherwise all is weil anc No Recovery is required (.¢. the normal case).
During the Log On process. f the counter receives an indication that recovery may be required (Le. one
of the two cases described above), then the following occurs before the Log On is completed
1. If Roliforward Recovery is requested, then for each Transaction with associated Recovery Data
then the appropriate Recovery script is executed. which will result in @ Roliforward Recovery
Basket being produced which is then settied to the Branch Database as normal and this will
generate a recovery Receipt. This will normally match any Disconnected Session receipt for
other information recorded at the time of failure)
2, if there was no Basket Details of a Last successfud Basket returned, then No Recovery is
required
3. ff further checks are requested, then the following checks are made at the counter:
a What was the identifier of the last successful Basket sent from the counter?
The identifier of the last successful Basket is written to the Counter Hard Disk at the
completion of the basket (Le. after aii Receipts have been successfully printed)
Therefore, provided that the Terminal has not been replaced, then this is available to be
checked for automatically.
Where the terminai has been physically replaced, a dialogue is invoked to get the user to
confirm the identity of the last Successful session which may involve displaying the last
basket known to the Data Centre.
b. If this matches the identifier of the Last Successful Basket that was returned from the
Data Centre, then No Recovery is required and all is well
cif they don't match (1e the Basket returned from the Data Centre was the one that the
counter was trying to save at the time of fallure), then the Forced Log Off process will
have assumed thai the Basket failed. Therefore the Recovery process needs to
generate a Basket that reverses any nor-recoverable transactions in that basket (since:
the forced Log Off would have discarded them). This is known as Rollback Recovery.
This will also produce a Receipt. However it will not match the Disconnected Session
Receipt exactly
2.4 Database Characteristics
The database uses Oracle version 10gR2. It uses an Oracle Reel Applic:
the database over mulliple nodes (servers). In practice there are normally 4 s
in Cluster (RAC), which runs
ch database nodes
Parttioned tables s ranch specific data. This provides high performance and scalabihty.
Applications need to know in which partitions data is stored and which nodes manage these partit
They use @ canvention based on Branch codes.
The &
gn of the Branch Database supports non-stop trading during core hours.
Bare RU TST RE TED COMMERCIAL
ONPIDENCE
SCopyight Pulse Servic
Uncontolied if Printed or Distributed
FUJ00124015
FUJ00124015
oO Horizon Online Data Integrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
« Oracie RAC is resilient. if one node fails. the remaining nodes carry on running and the
database remains available for use. The database can meet its performance targets if one node
fails
» The standby databese ellows very fast recovery if there is a data corruption thet takes the live
database offiine. The maintenance of the standby database is automatic.
A disaster recovery site remotely mirrors the data. The mirroring of data is synchronous. This guarantees
that no data is lost if there is a catastrophic site failure.
Data associated with a Basket is stored in 3 separate areas of the Branch database:
1. A copy of the actual Basket data as transmitted from the counter together with the associated
digital signature is held in a table known as the message journal
Use of the data in the message journai is described further in section 3
2. Individual accounting lines are extracted from the basket and each accounting line is written to
two separate tables
a} Detailed transaction information for passing to Post Office Ltd Back end systems
This data is retained for sufficient time to ensure it has been successfully passed to Post
Office Lid’s back end systems (in practice it is held for about 4 days)
Summary transaction information te support reporting and Branch accounts
This data is retained to allow it to be used for any reporting and accounting period within
the branch (in practice it is held for about 60 days}
Each night the reporting data is summadsed within the branch database to provide daily totals for
transactions based on product, mode. stock and accounting period. This summansed data is used
{together with transactions for the current day) when balancing a stock unit, thus minimising the amount
of data that needs to be considered,
Although the data used for generating the counter reports and passing to Post Office Ltd's back end
systems is taken from the tables described in point 2 above, any data provided by Fuptsu in order to
support litigation is based on the Audit taken at point 1 above. Since the processing for producing any
report is based on the same source of data (ie the audited data sent from the counter) itis asserted that
any report could be regenerated based solely on the audited data. As described in section 2.1, the
audited data consists not orly of the Basket information, but also any other significant events and in
particular the Opening Figures (je cash and stock levels) calculated at the start of a new period based on
the balancing of an accounting period
Ll should be noted that such dates is non presented as ewidetce «x part of the 1 Aiglion
des not have tools tat extract data such ax Opening Figures into ar
vd on the audit trail, However such dates is availa
ity be developed ta resolve av dispute
I service. Similarly we
form or ta bx
I the andi
rns of the cost wand cffort
Copyright Pusu Servioes Lid 2072 PURTS! AMERCIALIN: Ret
Uncontrotied if Printed or Distritaited
FUJ00124015
FUJ00124015
oo Horizon Online Data fr
egrity for Post Office Lid
FUJITSU FUJITSU RESTRICTED - COMMERCIAL IN CONFIDENCE
3 Audit System
As outlined in section 2.1 and described in section 2.4. any auditable message frorn the counter is stored.
logether with its Digital Signature and other key attributes in an “Audit table” (known as the Message
Journal) in BRDB
To ensure that he message is not tampered with after being sent from the counter, each message has
an associated Digital Signature. The mechanism for creating this Digital Signature is as follows
4. AtLog On, the Counter creates an RSA Public / Private key pair.
2. The Public key is sent to the BAL as part of the audited Log On message
3. The Log On message is concatenated with the Digital Signature and the BAL’s signing certificate
for its Public Key and signed by a BAL Private key (held in the data Centre Key Store) and added
to the audit trail with a BAL generated js
4. All subsequent messages are digitally signed by the counter using the private key established at
Log On
5 Digitally Signing a message involves taking a SHA-1 Hash of the message and digitally signing
the Hash value using RSA.
6. The Digital signature is stored alongside the message in the Journal table and is extracted with it
into the Audit file as described below
Each night after midnight, the contents of this table for the previous day are copied from the BRDB to a
number of serial files,
ine to the voluaie of i
id into a smadi number of thes
Hh POC
f number of uch day. AU data from a given
Bb
4 for ease of re
ranch will be concentrate
At this point a check is made that indeed there are no missing or duplicate isns for any counter and
should any be found an alert is raised.
ov semehody tampering with the
or any suck baege / tampering,
ute thal this could onh
data in BRDB and this ft
result uf a bug in
fnchasted specifically to ch
These files are then copied to the Audit system where they are sealed with digital seals. They are held
there for a period of 7 years during which time they may be retrieved and filtered to produce the relevant
audi data for a particular Branch.
The Digital Seal is calculated using an MDS hash of the entire content of the file being sealed. This value
is Stored in a separate “Seals Database” held on the Audit Server
'S a number of checks are carried out:
Whenever data is retreved for audit enqui
a} The audit have not been tampered with (Le. the Seals on the audit fles are correct)
b} The individual Bask {and other records) have their digital signatures checked to ensure that
they have not been corrupted
Log On message wind us
ag the Public Key Certificate of the BAL’s s
og Onn audit sien:
s3idg
j@ that no records are missing 0:
ates in the jsn sequence for any
plicated. Le. a check is made that there are no
gaps or dupli
it shoukd be noted that this same Audit system was used to hok
on the off Horizon system the audit point was t
nology used for pr
nd Horizon Online.
ar data frorn the old Horizon sys
journal on the Riposte
y the audit of data is completely
yight Fustse Se
‘Uneontrolied it Printed or Distrituted