trusted archiving authority - ltans
Post on 20-Oct-2014
1.639 views
DESCRIPTION
an overview of all topics and applications to build a trusted archiving authority (TAA) aligned with LTANS.TRANSCRIPT
page 1 • Fedisa_TAA
03-23-05Juni 2011
TAA-Trusted Archive AuthorityTAA-Trusted Archive Authority
Presented by Jan Biets
[email protected] +32(0)477 32 90 11 Mechelen - Belgium
page 2 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
““PRE” PRE”
All rights reserved by the author.
No citing, abstracting, or other usage is permitted without written permission
Contact address: [email protected]
page 3 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
AgendaAgenda
Definitions:
LTANS:
• Long-Term Archive and Notary Services
TAA:
• Trusted archive authority
• Description TAA.org:
“A TAA accepts data for long-term storage and is responsible for ensuring that an evidence trail is produced and stored to enable demonstration of data integrity at any point in the future. “
Non-repudiation - undeniable - legally binding
page 4 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TSA
E-SIGN
CA - PKI
ERS
Management
LAW
Policy
Security
Business Process
User interface
Agenda Agenda
page 5 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
law & standards
managed documented
othermodules
operations
TAA
Agenda Agenda
page 6 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
RFC3281 : An Internet Attribute Certificate Profile for AuthorizationRFC3280 : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC3369 :Cryptographic Message Syntax (CMS) RFC3126 : Electronic Signature Formats for long term electronic signaturesRFC3161 : Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)RFC2459 : Internet X.509 Public Key Infrastructure Certificate and CRL Profile PKCS#7 : Cryptographic Message Syntax Standard PKCS#11 : Cryptographic Token Interface Standard PKCS#12 : Personal Information Exchange Syntax Standard FIPS PUB 186-2 digital signature standard RfC 4871 - DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Service Overview draft-ietf-dkim-overview-10 (11 juli 2008)RfC 3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileRfC 5055 - Server-Based Certificate Validation Protocol (SCVP)RfC 3379 - Delegated Path Validation and Delegated Path Discovery Protocol RequirementsETSI 201 733 - ETSI Electronic Signatures and InfrastructuresACVS: An Advanced Certificate [RFC0989] Linn, J. and IAB Privacy Task Force, "Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures", RFC 0989, February 1987.[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. INTERNET DRAFT DKIM Service Overview February 2008 Hansen, et al. Informational [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
TAA – the complexity (?)TAA – the complexity (?)
page 7 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – functional architectural designTAA – functional architectural design
IAM
CATSA
DMS
ERS
i-Sign
HW
Event logging
(audit trail)
storage
SA*
Abbreviations:
IAM – identity & access management
CA – Certification authority
RA – registration authority
SA – “source authentic”
ERS – Evidence record syntax
page 8 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - IAMTAA - IAM
CA – PKI and RA: strong identification and access management (authorisation)
– “face to face” issuing smart cart / token,
– Based on authentic source (SA):
• database of members of closed environment / target public.
• Accurate management of authentic source, and respectively authorisations.
– Class 3: for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority.
Abbreviations:
CA - Certification Authority , ETSI TS 101 456
PKI - Private Key Infrastructure,
SA – “source authentic”
RA - Registration Authority , ETSI TS 101 456
page 9 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - electronic signatureTAA - electronic signature
XAdES (XML Advanced Electronic Signatures) is a set of extensions to XML-DSig recommendation making it suitable for advanced electronic signature.
Xades XL,
• extended long-term, adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available;
• XAdES specifies precise profiles of XML-DSig for use with advanced electronic signature in the meaning of European Union Directive 1999/93/EC.
• One important benefit from XAdES is that electronically signed documents can remain valid for long periods, even if underlying cryptographic algorithms are broken.
Based on:
Xades , ETSI 101 903
page 10 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - electronic signatureTAA - electronic signature
Legal points of interest / attention:
• sometimes constraints: only one copy as the original !
• or not allowed to store abroad (difficult to verify on internet!)
• sign documents individually (not batch files)
• use Pdf-a format
Based on:
Xades , ETSI 101 903
page 11 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - TSATAA - TSA
The technique is based on digital signatures and hash functions. First a hash is calculated from the data. A hash is a sort of digital fingerprint of the original data: a string of bits that is different for each set of data. If the original data is changed then this will result in a completely different hash. This hash is sent to the TSA. The TSA concatenates a timestamp to the hash and calculates the hash of this concatenation. This hash is in turn digitally signed with the private key of the TSA. This signed hash + the timestamp is sent back to the requester of the timestamp who stores these with the original data (see diagram).
• Since the original data can not be calculated from the hash (because the hash function is a one way function), the TSA never gets to see the original data, which allows the use of this method for confidential data.
Abbreviations:
TSA - Timestamp Authority , ETSI TS 102 023
page 12 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - TSATAA - TSA
Abbreviations:
TSA - Timestamp Authority , ETSI TS 102 023
page 13 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - managementTAA - management
Management has to provide:
• a set of resources (budget , and other means) , to enable the execution of the projects (programme) and
• the operations of the applications (well defined roles and responsibilities, policies , and a suitable organisation)
page 14 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - managementTAA - management
page 15 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - other elements TAA - other elements
• Business Case
– Why, what, how (justification)
• Risk assessment
– What are the risks “what if not”
• Business Process Flow
– Define the streams of the document flows
• DMS
– Choice ‘commercial’ product , or open source
– User interface (GUI)
Abbreviations:
DMS - Document Management System,
GUI – Graphic User Interface
page 16 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA - approachTAA - approach• creating a system to enable the TAA service :
– policy, • A policy is typically described as a principle or rule to
guide decisions and achieve rational outcome(s). • a policy will contain the 'what' and the 'why',
– Obligations and liability– Records to be deposited– Time of deposit (retention)– Data integrity, and access continuity assurances– Accepted formats
– processes, – procedures,
• procedures (or protocols) contain the 'what', the 'how', the 'where', and the 'when'.
– security,– infrastructure/architectural design and– audit
• Verify: systems, documents, and operations
page 17 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – Risk assessment 360°TAA – Risk assessment 360°
(off-site)Back-up
policy
ICT room
policies processes
People & staff
Physical security
operations
TAA
page 18 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – Risk assessment 360°security tiers)TAA – Risk assessment 360°security tiers)
Policy Security
Policy H
R
Trusted Archival Authority
Physical Security
Building Security
Policy Security
Application security
Server room
Org
anis
atio
n &
man
agem
ent
Pol
icy
System Security
Authorisation & authentification
Network Security
User interface Security
procedures people
page 19 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – basic functionalities and features of a DMSTAA – basic functionalities and features of a DMS
• Depose documents
• User management
• Access control
• Document life cycle management (retention policy)
• Audit trail (event logging)
• Proof of document integrity
• Web access (intranet, internet)
• Document management system (user interface),
page 20 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – functionalities: audit trail (logging of events)TAA – functionalities: audit trail (logging of events)
System:
– Authorisation matrix
– Change file detection
– Log file is encrypted
– Secure logging
– Operator alerts
– System alarms
– System modifications have to be done by ‘system administrator’ + logging (+ documented)
Based on results of risk assessment
1/2
Remark:CWA 14167-1. Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures
page 21 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA –functionalities: audit trail (logging of events)TAA –functionalities: audit trail (logging of events)
• Procedures
– 4-eyes (or more) in case system operations / modifications
– Administrator access management by means of smart card and certificate by CSO
• Dashboard (events)
– Authorisation matrix
– Configuration user management , access management modifications
– Who has, when , what document deposed, modified, consulted, changed, deleted, shared?
2/2
Remark:CWA 14167-1. Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures
Abbreviations:
CSO – Chief Security Officer
page 22 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – basic functionalities: user managementTAA – basic functionalities: user management
• (system) authority assigns access rights to users
• User management data (access rights) information exchange via Certificate smart card, and authentic source;
– Roles:
• Authority
• Employee
• System administrator (local office/authority)
– Responsibilities:
• Depose
• Copy
• Share
• Delete
• View
• Annotate
• (other actions)
Based on results of risk assessment
page 23 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – functionalities: proof of integrityTAA – functionalities: proof of integrity
• System generates ‘ERS’ per document, to proof long term evidence (non-repudiation / undeniable )
• Kind of ‘fingerprint’
– Timestamp
– Electronic signature
– Certificate (status)
– Root chain certificate
– Hashing (verification / proof of ‘un-changed’ status of content
• System regenerates periodically ERS (based on certificate life cycle)
Abbreviations:
ERS – Evidence record syntax
page 24 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – TAA – Overview of Archiving FeaturesOverview of Archiving Features
Archived object
Could be any electronic file / data.
Object meta-dataAuthor, category, size, version, date, key-word
Digital SignatureRelevance is depending on legal requirements.
it is mandatory to proof the legal ‘serieux’ of the users;
‘legal note’:Do not sign ‘batch’ –files , nor ‘zip’-ed formats.
Archived Object
Object META -DATA
Digital Signature(optional )
Complementary data
Archive meta -data
Evidence record
Ob
ject
’sco
n ser
vat io
n a
ttrib
ute
s
page 25 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – ERS , Overview of evidence record syntaxTAA – ERS , Overview of evidence record syntax
Archived Object
Object META-DATA
Digital Signature(optional)
Complementary data
Archive meta-data
Evidence record
Obj
ect’s
cons
erva
tion
attr
ibut
es
Complementary data•Digital certificate•Certificate chain•Certificate revokation list
Archive meta-data•Document owner•Archival time•Origin of document
Evidence record•Document finger print•Timestamp•Hash link
page 26 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – basic architectural designTAA – basic architectural design
Hardware &
Storage
Policy &
Procedures
Web Service
DMS – user
interface
ERS engine
TSA
Security &
Legal
page 27 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – functional architectural designTAA – functional architectural design
IAM
CATSA
DMS
ERS
i-Sign
HW
Event logging
(audit trail)
storage
SA*
Abbreviations:
IAM – identity & access management
CA – Certification authority
(RA – registration authority)
SA – “source authentic”
ERS – Evidence record syntax
page 28 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – architectural designTAA – architectural design
S1
S2
S3
S4
Abbreviations:
LTAP – long term archival protocol
ERS – Evidence record syntax
page 29 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
AfterwordAfterword
• Business case, justification
• Risk analysis, threat , vulnerability
• Legal:
– sometimes constraints: only one copy as the original !
– Sometimes not allowed to store abroad (difficult to verify on internet!)
– Sign documents individually (not batch files)
– Advice to use Pdf-a format
• Business process flow;
• Select technology;
• Usability, user friendly GUI;
page 30 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
Afterwords : points of attention during conceptual designAfterwords : points of attention during conceptual design
• Recoverability and Data Integrity
• Architecture / Design to achieve required availability
• Reliability
• Manageability
• Backup and Recovery
• Performance
• Scalability [Not every application supports more transactions or more users when adding CPU and Memory]
• Installation Requirements
• Configuration Requirements
• Maintainability Requirements
• Localisation / Internationalisation Requirements & constraints
• Operations-, Support- and Troubleshooting Requirements
• Documentation Requirements
• Monitoring: Application Level Monitoring must be explicitly requested, otherwise you just get system- and database monitoring.
• Archiving and Restoring
page 31 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – some other fields of applicationTAA – some other fields of application
1. Liberal professions, have in some cases long term - legal- responsibilities, i.e.
– Lawyers
– architects : a 10 year professional responsibility for building plans
– accountants : also responsible for VAT declarations
– auditor/revisor (head of accountants): signing of fiscal year documents/statements
2. Log files
– log files (systems, applications,...) should not be changed, only by dedicated staff (i.e. chief security officer), and applicable policy, or local laws
3. Banks, insurance companies; stock exchange
– approval of credits and loans: who has done what in accordance of the mandate
– timeline and sequence (order) of the performed transactions (using time-stamping)
4. Medical statements and medicines prescription
– patients' medical records in electronic form
page 32 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – basic functionalities: proof of integrityTAA – basic functionalities: proof of integrity
5. Justice (ministry)
– defined and traceable work streams
– from police statement to lawyers and judges, and classification of files: every ‘role’ has added, viewed, changed documents.
– Files can not be changed by un-authorised people, nor been lost, with dramtic legal consequences
6. Patenting (every country has a patent office; patent is public information)
– to be able to prove who was first to come up with an idea or to patent a document, drawing, design, music score, research results,...
– Escrow
7. IPP (intellectual property protection)
– research companies have a legal trace of the progress of the search for a new product
– this can/could be private information (un-disclosed for third parties)
page 33 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TAA – basic functionalities: proof of integrityTAA – basic functionalities: proof of integrity
8. Registered mail
– electronic mail with proof of content, 'addressee", time , and acceptance
9 . Closed environments
– tax governments, pension authority, banks, insurances, stock exchange (logging of transactions),....
10. Accounting services companies
– storage of accounting companies customers' documents in electronic format– outsourced electronic archiving (is implemented in some Eastern European countries)
11. Apostilles:
– It specifies the modalities through which a document issued in one of the signatory countries can be certified for legal purposes in all the other signatory states. Such a certification is called an apostille (French: certification). It is an international certification comparable to a notarisation in domestic law.
12. Invoices:
– Electronic invoices archival, helpdesks, customer’s service , legal purposes.
page 34 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
Questions?Questions?
?????
page 35 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
Certificate classification (Verisign)Certificate classification (Verisign)
• VeriSign uses the concept of classes of digital certificates
– Class 1 for individuals, intended for email.
– Class 2 for organizations, for which proof of identity is required.
– Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority.
– Class 4 for online business transactions between companies.
– Class 5 for private organizations or governmental security.
https://www.verisign.com/support/roots.html
page 36 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatureselectronic signatures[3][3] defines the term defines the term qualified qualified certificatecertificate as: as:
"a certificate which meets the requirements laid down in Annex I and is provided by a certification-service-provider who fulfils the requirements laid down in Annex II":
• Annex I: Requirements for qualified certificates
• Qualified certificates must contain:
(a) an indication that the certificate is issued as a qualified certificate;
(b) the identification of the certification-service-provider and the State in which it is established;
(c) the name of the signatory or a pseudonym, which shall be identified as such;
(d) provision for a specific attribute of the signatory to be included if relevant, depending on the purpose for which the certificate is intended;
(e) signature-verification data which correspond to signature-creation data under the control of the signatory;
(f) an indication of the beginning and end of the period of validity of the certificate;
(g) the identity code of the certificate;
(h) the advanced electronic signature of the certification-service-provider issuing it;
(i) limitations on the scope of use of the certificate, if applicable; and
(j) limits on the value of transactions for which the certificate can be used, if applicable.
page 37 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatures.electronic signatures.• Annex II Requirements for certification-service-providers issuing qualified certificates
(a) demonstrate the reliability necessary for providing certification services;
(b) ensure the operation of a prompt and secure directory and a secure and immediate revocation service;
(c) ensure that the date and time when a certificate is issued or revoked can be determined precisely;
(d) verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued;
(e) employ personnel who possess the expert knowledge, experience, and qualifications necessary for the services provided, in particular competence at managerial level, expertise in electronic signature technology and familiarity with proper security procedures; they must also apply administrative and management procedures which are adequate and correspond to recognised standards;
(f) use trustworthy systems and products which are protected against modification and ensure the technical and cryptographic security of the process supported by them;
(g) take measures against forgery of certificates, and, in cases where the certification-service-provider generates signature-creation data, guarantee confidentiality during the process of generating such data;
(h) maintain sufficient financial resources to operate in conformity with the requirements laid down in the Directive, in particular to bear the risk of liability for damages, for example, by obtaining appropriate insurance;
(i) record all relevant information concerning a qualified certificate for an appropriate period of time, in particular for the purpose of providing evidence of certification for the purposes of legal proceedings. Such recording may be done electronically;
(j) not store or copy signature-creation data of the person to whom the certification-service-provider provided key management services;
(k) before entering into a contractual relationship with a person seeking a certificate to support his electronic signature inform that person by a durable means of communication of the precise terms and conditions regarding the use of the certificate, including any limitations on its use, the existence of a voluntary accreditation scheme and procedures for complaints and dispute settlement. Such information, which may be transmitted electronically, must be in writing and in readily understandable language. Relevant parts of this information must also be made available on request to third-parties relying on the certificate;
(l) See next slide…
page 38 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatures.electronic signatures.
(l) use trustworthy systems to store certificates in a verifiable form so that:
only authorised persons can make entries and changes,
information can be checked for authenticity,
certificates are publicly available for retrieval in only those cases for which the certificate-holder's consent has been obtained, and
any technical changes compromising these security requirements are apparent to the operator.
page 39 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
The The EU EU DirectiveDirective 1999/93/EC on a Community framework for 1999/93/EC on a Community framework for electronic signatures : electronic signatures : Profiles
XAdES defines six profiles (forms) differing in protection level offered. Each profile includes and extends the previous one:
XAdES, basic form just satisfying Directive legal requirements for advanced signature;
XAdES-T (timestamp), adding timestamp field to protect against repudiation;
XAdES-C (complete), adding references to verification data (certificates and revocation lists) to the signed documents to allow off-line verification and verification in future (but does not store the actual data);
XAdES-X (extended), adding timestamps on the references introduced by XAdES-C to protect against possible compromise of certificates in chain in future;
XAdES-X-L (extended long-term), adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available;
XAdES-A (archival), adding possibility for periodical timestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during long-time storage period.
page 40 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
Xades, electronic signature compositionXades, electronic signature compositionThe XAdES-T envelope:contains a trusted timestamp over the signature. The goal is to prove that the signer’s certificate was valid at the time of signature.
The XAdES-X envelope: “When an OCSP response is used, it is necessary to time-stamp in particular that response in the case the key from the responder would be compromised” In other words, the goal is to prove that the OCSP responder’s signing certificate was valid at the time of OCSP response.
“The SignatureTimeStamp encapsulates the time-stamp over the SignatureValue element.”
XADES : XML Advanced Electronic SignaturesSpecification from the ETSI that is built upon the Xmldsig specification.It provides “signatures that remain valid over long periods.
XAdES-X-L
XAdES-X
XAdES-C
XAdES-T
XAdES-EPES
OCSP
Timestamp
Certificates Chain
Timestamp
XAdES - a Timestamp
page 41 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
Xades, electronic signature Xades, electronic signature compositioncomposition
page 42 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
““Xades – A”, electronic signature Xades – A”, electronic signature compositioncomposition
• Signed Signature Properties • Signing Time (non-authoritative: may be from signer’s computer) •Signature Certificate •Signature Policy Identifier •Signature Production Place (optional) •Signer Role (optional)
•Signed Data Properties •Data Object Format * •Commitment Type Indication * •All Data Objects Time Stamp * •Individual Data Objects Time Stamp *
•Unsigned Signature Properties •Counter Signature * •Signature Timestamp+ •Complete Certificate Refs •Complete Revocation Refs •Refs Only Time Stamp - or – Sig and Refs Time Stamp •Certificate Values •Revocation Values
•Archive Time Stamp +
page 43 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
Xades, electronic signature process flowXades, electronic signature process flow
Electronic document
Creation (Pdf)
DocSign
Signature PIN code
TimeStamp
Public Key Verification
OCSP Verification
INPUT
Electronic document
Creation (Pdf)+
Timestamp profile
OUTPUT
0
12
3
4
5
6
78 9
E-sign
page 44 • FedisaTAA – Trusted Archive Authority , Fedisa Juni 2011
TSA – timestamp , process flowTSA – timestamp , process flowRequest
Time stamp
Verify validity certificate
logging
Verify validity > 1 < second
logging
Set Time stamp
TimeStampAccording ETSI TS 102 023
System audit process