Adss Server Trusted Archive Services (Tas Aug08)

1,147 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,147
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
22
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Adss Server Trusted Archive Services (Tas Aug08)

  1. 1. ADSS Server / Trusted Archive Server Saving Time & Money, Avoiding Risk & Fraud
  2. 2. Agenda <ul><li>ADSS Server </li></ul><ul><ul><li>Key features </li></ul></ul><ul><li>ADSS Server </li></ul><ul><ul><li>Current Signing / timestamp capabilities </li></ul></ul><ul><li>Trusted Archive Server </li></ul><ul><ul><li>Interaction with ADSS Server </li></ul></ul><ul><li>Requirements & Standards </li></ul><ul><li>Archive Process </li></ul><ul><li>Refreshing Evidence Records </li></ul>
  3. 3. Why use ADSS Server Trust Services? <ul><li>Maximises options and enables easy usage </li></ul><ul><ul><li>Supports multiple document formats </li></ul></ul><ul><ul><li>Supports multiple signature locations and formats </li></ul></ul><ul><ul><li>Creates and verifies one or more corporate signatures, end-user signatures </li></ul></ul><ul><li>Minimises internal effort to apply trust </li></ul><ul><ul><li>High level services – even using just one line of code ! </li></ul></ul><ul><ul><li>Manages all keys, certificates, external authorities, etc </li></ul></ul><ul><ul><li>Built-in management, logging, audit, reporting </li></ul></ul><ul><li>A world-class product for today and tomorrow </li></ul><ul><ul><li>All the required business trust services in one product </li></ul></ul><ul><ul><li>Supports multiple concurrent applications </li></ul></ul><ul><ul><li>High availability and scalability </li></ul></ul><ul><ul><li>Easy to use, fully managed, controlled security </li></ul></ul>
  4. 4. Ascertia ADSS Server Integration Options Note: You only need license and use what is needed today ADSS Server Web Services - via XML/SOAP messaging - via a provided high level .NET API - via a provided high level Java API Using ADSS GoSign - Within a web-browser (GoSign Applet) - Within a desktop .NET app (GoSign .NET) - Within a desktop Java app (GoSign Java) Using ADSS Server Auto File Processor - For one or more watched folders Using ADSS Gateway for confidentiality - to extract signatures from documents Using the Secure eMail Server - to handle emails and/or attachments ADSS Server HTTP fast interface - For Signing and Verification services Sign Verify       Q3 2008 Q3 2008   -         
  5. 5. Ascertia ADSS Server Trust Services Note: You only need license and use what is needed today PDF Documents - Basic signature (visible / invisible) - Certify - Sign & timestamp - Long-term signatures XML Documents - XML DSig (XAdES ES) - Timestamps (XAdES ES-T) - Long-term signatures (XAdES X-Long) PKCS#7 / CMS / SMIME - Basic signature (CAdES ES) - Timestamps (CAdES ES-T) - Long-term signatures (CAdES X-Long) Historic Verification OCSP Validation (immediate verify & long term sign) Time Stamp Authority (TSA) Server Sign Verify                     -     
  6. 6. ADSS Server Product Architecture Application Web Services Application Java API Email Gateway Watched Folder OCSP Clients SCVP clients XKMS clients using HTTP HTTP/S XML/SOAP Synchronous Asynchronous    = Q1 2008
  7. 7. ADSS Notary Signing / Archive Options <ul><li>ADSS Server supports Notary services today - driven by a business application </li></ul><ul><ul><li>Sign / Sign & Timestamp / Long-term signatures </li></ul></ul><ul><ul><li>As PDFs wrapped objects </li></ul></ul><ul><ul><li>As XML wrapped objects (future includes XAdES/A) </li></ul></ul><ul><ul><li>As PKCS#7/CMS objects </li></ul></ul><ul><ul><li>Timestamp “Postmarks” (delivered if required) </li></ul></ul>
  8. 8. Archiving Standards <ul><li>Standards in this area are not yet stable </li></ul><ul><li>IETF Long-Term Archive and Notary Service (LTANS) group: </li></ul><ul><ul><li>Long-Term Archive Protocol: provides the request/response message specs for communicating with TAS ( http://www.ietf.org/proceedings/07dec/IDs/draft-ietf-ltans-ltap-05.txt ) </li></ul></ul><ul><ul><li>XML Evidence Record Syntax (XMLERS): provides details on the structure of timestamp evidence records and the renewal process </li></ul></ul><ul><ul><li>(http://www.ietf.org/proceedings/07dec/IDs/draft-ietf-ltans-xmlers-00.txt) </li></ul></ul>
  9. 9. Trusted Archive Server <ul><li>Ascertia’s Trusted Archive Server will follow the IETF LTANS draft standard </li></ul><ul><li>Features </li></ul><ul><ul><li>Provides built in archive application functions </li></ul></ul><ul><ul><li>Delivery Q3 2008 </li></ul></ul><ul><ul><li>Multiple profile options for signing, verification, timestamping, archive, re-evidencing, deletion. </li></ul></ul>
  10. 10. Interaction with ADSS Server ADSS Server Trusted Archive Service ADSS Enterprise Server offers a variety of digital signature creation, verification, timestamp client and validation services ADSS Infrastructure server offers CA, TSA and OCSP VA services LTANS Archiving Timestamp client OCSP Client Trusted Archive Server CRL Manager Verification Signature Draft IETF LTANS processing of archive requests Multi-policy archive management CAs TSA VA Signature Verification Service Signature Generation Service
  11. 11. Trusted Archive Server <ul><li>Key Features: </li></ul><ul><li>Provide time based evidence of existence </li></ul><ul><ul><li>that electronic documents or data (emails, audit data, reports) existed at a particular moment in time </li></ul></ul><ul><li>Ensure data authentication / integrity </li></ul><ul><ul><li>To prove that throughout the entire archival period the data has not changed </li></ul></ul><ul><li>Provide a means of refreshing the security </li></ul><ul><ul><li>Today’s security measures can only last a defined period so the Trusted Archive Server must be capable of ensuring the validity of its archived data and documents for the required archival period, i.e. beyond certificate expiry/revocation, timestamp expiry and weakness in key lengths and hash or signing algorithms </li></ul></ul>
  12. 12. Data types that can be archived <ul><li>Submitters can archive any type of data, including: </li></ul><ul><li>Raw data </li></ul><ul><ul><li>i.e. unsigned, unencrypted </li></ul></ul><ul><li>Signed data </li></ul><ul><ul><li>Including PDF, PKCS#7/CMS, S/MIME, XML DSig </li></ul></ul><ul><li>Advanced Signatures </li></ul><ul><ul><li>Including CAdES, XAdES and PDF long-term signatures </li></ul></ul><ul><li>Encrypted data </li></ul><ul><ul><li>treated as an opaque block </li></ul></ul>
  13. 13. Services offered by Trusted Archive Server <ul><li>Submitting of data objects to Archive </li></ul><ul><ul><li>Under a specified or default archive policy </li></ul></ul><ul><li>Searching within Archive objects </li></ul><ul><ul><li>within specified timeframes or data references </li></ul></ul><ul><li>Retrieval (export) of data objects from Archive </li></ul><ul><li>Requesting deletion of Archive objects </li></ul><ul><ul><li>Manual (role based permissions, dual controls) </li></ul></ul><ul><ul><li>Automatic deletion based on archive policy </li></ul></ul><ul><li>Verifying Archive object integrity </li></ul><ul><ul><li>Manual (role based permissions, dual controls) </li></ul></ul><ul><ul><li>Automatic check every policy set time interval </li></ul></ul>
  14. 14. Submitting basic data Verify request & client authorisation c Gather Archive Process Meta Data Request timestamp for full archive object c Trusted Archive Server Time Stamp Authority (e.g. Ascertia ADSS TSA Service) DB Meta data sent by client may include: Filename, Author details, digital signature, etc. Archive Process Meta data may include archiving time, retention period, cryptographic info, etc. ERS stands for Evidence Record Syntax – this includes the timestamp information obtained from RFC3161 compliant TSA (see next slide) Hash & Timestamp Submission by people or applications Data Object Meta Data Data Object Meta Data Archive Process Meta Data ERS
  15. 15. Evidence Record Syntax (ERS) <EvidenceRecord> <Version /> <ArchiveTimeStampSequence> <CanonicalizationMethod /> <ArchiveTimeStampChain Order> <DigestMethod /> <ArchiveTimeStamp Order> <HashTree /> * <TimeStamp /> + <CryptographicInformation /> * </ArchiveTimeStamp>) + </ArchiveTimeStampChain> + </ArchiveTimeStampSequence> </EvidenceRecord> An Evidence Record must contain at least one timestamps in the TimeStampChain Additional timestamps may be added as the old timestamp nears its expiry. These are all contained within a single TimeStampChain A new TimeStampChain is created with the underlying hash algorithms need to be renewed (due to weakness in original algorithm) Note: Ascertia ADSS TAS Service will use a timestamp for each data object rather than using hash trees. This provides best security and immediate response (compared to hash trees) . Support for Merkle hash trees will be added later
  16. 16. ERS - Timestamp Renewal Structure EvidenceRecord ArchiveTimeStampSequence ArchiveTimeStampChain Order =1 DigestMethod ArchiveTimeStamp Order =1 TimeStamp Cryptographic Information ArchiveTimeStamp Order =2 TimeStamp Cryptographic Information ArchiveTimeStampChain Order =2 The first timestamp is over the archive object including meta data Cryptographic Information is used to store CRLs/certs/TAs required to verify the timestamp A new timestamp is requested before expiry of a previous timestamp (or configurable period, e.g. annually). This timestamp is only over the last timestamp. A new chain is created when the digest algorithm is changed. Note this timestamp will be over original data object and all previous chains
  17. 17. Verify / Archive Signed Data Meta Data (e.g. detached signature) Verify request & client authorization c Gather Archive Process Meta Data Request timestamp for full archive object c Time Stamp Authority (e.g. Ascertia ADSS TSA Service) DB Meta data: may include detached signature, alternatively signature maybe enveloped inside document (e.g. signed PDF) Archive Process Meta data: signature will be verified, certificate chains, CRL/OCSP responses and final Trust Anchors (TAs) will be added as archive process meta data Verify signatures by gathering cert chains, OCSP responses, TAs OCSP Responder (e.g. Ascertia ADSS OCSP Service) <ul><li>TAS Service verifies existing signatures </li></ul><ul><li>Gathers signature verification info </li></ul><ul><li>Archives data object + signature verification info </li></ul>Trusted Archive Server Data Object
  18. 18. Verify / Archive Options <ul><li>Signatures may be: </li></ul><ul><ul><li>Detached (supplied separately from data) </li></ul></ul><ul><ul><li>Enveloped (e.g. PDF signatures, XML signatures) </li></ul></ul><ul><li>Document formats </li></ul><ul><ul><li>Any type of file with detached PKCS#7/CMS or XML DSig </li></ul></ul><ul><ul><li>PDF (with embedded PKCS#7 sig) </li></ul></ul><ul><ul><li>XML (with embedded XML DSig) </li></ul></ul><ul><li>Multiple signatures are supported </li></ul><ul><li>Long-term signatures are supported </li></ul><ul><ul><li>CAdES or XAdES with timestamps and revocation data </li></ul></ul>Note: ADSS Server Verification Service already supports the verification of all these complex and advanced signatures!
  19. 19. Notary Signing and Archiving Meta Data (e.g. detached signature) Verify request & client authorization c Gather Archive Process Meta Data Request timestamp for full archive object c Time Stamp Authority (e.g. Ascertia ADSS TSA Service) DB Archive Meta data will include a notary signature over the Archive Data object. This can be PKCS#7/CMS signature or XML DigSig ERS will cover the notary signature so that the whole package including notary signature is protected for long-term Compute a signature over Archive Object HSM (e.g. SafeNet LunaSA) Trusted Archive Server Signed Data Object
  20. 20. ADSS Server – Admin Console <ul><li>Web-based with strong client/server authentication </li></ul><ul><li>Easy to use management interface with role based access rights </li></ul><ul><li>Trusted Archive Server will follow the same principle </li></ul>Service Modules Utility Modules
  21. 21. ADSS Server – Customer Console <ul><li>A web-based customer console [Q4] </li></ul><ul><ul><li>Using strong user authentication with role based rights </li></ul></ul><ul><li>Able to recover archived data and process, e.g. </li></ul><ul><ul><li>Review Archive data and its associated information </li></ul></ul><ul><ul><li>Verify Archive data and original signatures, timestamps, etc </li></ul></ul><ul><li>Able to review transaction logs </li></ul><ul><ul><li>View, search, create reports </li></ul></ul><ul><ul><li>Only for requests / responses belonging to this Customer </li></ul></ul><ul><li>Able to make requests for service change </li></ul><ul><ul><li>E.g. Acceptable Trust Anchors </li></ul></ul><ul><ul><li>New Archive policies </li></ul></ul><ul><ul><li>Client Management – when multiple clients are assigned </li></ul></ul><ul><ul><li>Dual control based accept / reject by authorised ADSS operators </li></ul></ul>
  22. 22. Archive Profiles – to enforce controls <ul><li>ADSS TAS Archive Profile defines: </li></ul><ul><li>How long an archive object is to be archived for </li></ul><ul><li>Archive object deletion policy </li></ul><ul><ul><li>Delete at the end of the archive period </li></ul></ul><ul><ul><li>Allow to “fade” without refreshing the timestamps </li></ul></ul><ul><li>Deletion policy </li></ul><ul><ul><li>Can a client request the deletion of archive object under this profile </li></ul></ul><ul><li>Timestamp Authority (TSA) selection </li></ul><ul><ul><li>Defines TSA and policy for handling timestamp requests </li></ul></ul><ul><li>How often the evidence information is to be refreshed </li></ul><ul><ul><li>Never </li></ul></ul><ul><ul><li>After configurable time period (e.g. every 10 years) </li></ul></ul><ul><ul><li>A configurable period before the expiry of that TSA certificate (3 months before expiry of TSA cert) </li></ul></ul><ul><ul><li>When manually requested by the TAS administrators </li></ul></ul>Multiple Profiles can be defined within ADSS Trusted Archive Service (TAS) Client requests can reference the Archive Profile to be used (or the default one will be used) ADSS Client Manager defines which clients can use which Archive Profiles
  23. 23. Archive Profile – continued <ul><li>Signed data processing policy </li></ul><ul><ul><li>Defines if signatures are verified first </li></ul></ul><ul><ul><li>Final trust anchors and full certificate chains of each signature (and each OCSP response/CRL/timestamp) are also archived </li></ul></ul><ul><ul><li>OCSP is recommended over CRL due to the smaller size </li></ul></ul><ul><li>Notary Archive Signature policy </li></ul><ul><ul><li>Should the Archive Service itself sign the data being archived using a wrapping signature (CMS or XML DigSig)? </li></ul></ul><ul><ul><li>Archive Profile defines the key and signing algorithm to use </li></ul></ul><ul><ul><li>The notary archive signature is archived in full </li></ul></ul><ul><ul><li>The Notary signature may include its own timestamp (in this case need to store full crypto info for this timestamp) </li></ul></ul><ul><li>External ECM information policy </li></ul><ul><ul><li>Defines links to ECM Systems </li></ul></ul>
  24. 24. Data Storage within an ECM System Meta Data (e.g. detached signature) Verify request and ECM system authorisation c Create response and send to ECM using identifiers provided in the request, logs to DB c ADSS TAS Service DB Process Archive Service request (Archive, Verify, Export, Search Request System: Could be any system, but expected to be the ECM (or EPM, ERP or CRM) system ERS data: This is not stored in ADSS TAS database area but passed back to defined ECM system for secure storage and retrieval under given identifiers. ECM system is responsible for storing data Object, Meta data, Archive Process Meta Data and ERS data Transaction Data: The request / response details are held by ADSS Server within the TAS transaction log and the actions and results can be viewed there, provides details of ECM storage identifiers Archive Process Meta Data ERS data ECM System Archive request Archive response/ data management Option to return all data to the ECM environment Data Object c LOGS
  25. 25. Authenticating and Authorising Clients <ul><li>ADSS Server Clients </li></ul><ul><ul><li>Registered within Client Manager module </li></ul></ul><ul><ul><li>Authentication options defined for signed requests or requests over Client/server mutually authenticated SSL or application ID </li></ul></ul><ul><li>Fine Grained Client application authorisation </li></ul><ul><ul><li>To submit data for specific Archival Profiles </li></ul></ul><ul><ul><li>To retrieve / export archive objects from archive </li></ul></ul><ul><ul><li>To delete archive objects </li></ul></ul><ul><ul><li>To verify archive objects </li></ul></ul><ul><ul><li>To request information on archive objects </li></ul></ul><ul><li>ADSS Server provides security management </li></ul><ul><ul><li>Authenticated each client (signatures & certificates are checked </li></ul></ul><ul><ul><li>Authorisation rights are confirmed </li></ul></ul><ul><ul><li>Secure Transaction logs are created </li></ul></ul>
  26. 26. Trusted Archive Server Security <ul><li>ADSS Server has security designed in </li></ul><ul><ul><li>Optional dual controls for all operator actions </li></ul></ul><ul><ul><li>Designed to meet CWA requirements </li></ul></ul><ul><ul><li>Strong authentication of all administrators / operators </li></ul></ul><ul><ul><li>Fine-grained role-based operator rights </li></ul></ul><ul><ul><li>HMAC secured logs with view, search, report options </li></ul></ul><ul><ul><li>Log and email alerting system </li></ul></ul><ul><li>ADSS Server supports multiple clients </li></ul><ul><ul><li>Strong client authentication with certificate based trust </li></ul></ul><ul><ul><li>Strong client authorisation based on client and service profiles </li></ul></ul><ul><li>FIPS 140 and CC EAL 4 HSMs are supported </li></ul><ul><li>SQL Server EE and Oracle RACs are supported </li></ul>
  27. 27. ADSS Server Scalability / Resilience CRLs CRLs CRLs OCSP OCSP OCSP Hardware Load Balancer ADSS Server Database replication E.g. Big-IP Cisco HSM 1 ADSS Server HSM 2 SQL Server or Oracle or PostgreSQL Archive requests and responses Option for 1 or more CAs supported Optional HSMs CA 1 CA 2 CA n
  28. 28. Use Case Example - Workflow Archive services Request Sign Protect Review Approve Countersign Later audit / review ERP CRM ECM Verify Verify ADSS Server + TAS Sign & Timestamp Evidence Archive Approval required business flows Approval granted business flows
  29. 29. Summary <ul><li>Meets all business needs for easy to deploy secure archive and archive management </li></ul><ul><ul><li>Documents, transactions and even email </li></ul></ul><ul><li>Easy to integrate </li></ul><ul><ul><li>A separate security service for any business application </li></ul></ul><ul><ul><li>High level .NET and Java APIs with sample applications </li></ul></ul><ul><ul><li>An option on signature creation or verification requests </li></ul></ul><ul><ul><li>Secure eMail Server integration </li></ul></ul><ul><li>Multi-platform </li></ul><ul><ul><li>Windows 2003 Server </li></ul></ul><ul><ul><li>Unix: Solaris (Sparc, X86) and other Unix options by request </li></ul></ul><ul><li>Secure Storage </li></ul><ul><ul><li>Uses industry leading databases with secured content </li></ul></ul><ul><li>Secure Management </li></ul><ul><ul><li>A well proven multi-functional platform with security designed in </li></ul></ul>
  30. 30. Questions: Rod Crook +44 1256 895416 [email_address]

×