Certificate authority for internal use plus e tax and e-policy01

1. Certificate Authority for Internal
Use Plus e-Tax and e-Policy
1, Soi Phutthabucha 2,Phutthabucha Rd.,
Bangmod Sub district.
Jomthong District, Bangkok 10150, Thailand.
Tel : +66(0)24278216 Fax : +66(0)24278217
Mobile : +66(0)61-6394914 ,+66(0)86-4144392
Line ID : Ohayo007
COVERSPACE CO., LTD.

2. 2
DIGITAL CERTIFICATES

3. 3
Real World ID Certificates
> Proving who you are in the real world
> The government (TTP) vouches for identity
> If the certificate looks authentic, identifying marks, as picture,
identify the person
> Printed to make it hard to forge
Name: James Bond
Address: Somewhere
Date of Birth: 1954
State of Fleming– ID certificate

4. 4
Digital Certificates – Digital ID
>A Digital document,
containing the public key +
identity information, digitally
signed by a Certificate
Authority (CA).
>The public key replaces the
photo For digitally verifying
the user’s identity.
>If the CA is trusted, a
Challenge-Response
protocol can be used for
authentication.
Name: James Bond
email james@serv.com
Public Key: 1f 0a 01 15 96
9a 5a 1c cc ab 1b f1 13 e8
Expiry Date: 3/5/00
CA Name: VeriSign
CA Signature: 15 2f 36 1a

5. 5
Real vs. Digital Certificates
Name: James Bond
Address: Somewhere
Date of Birth: 1954
State of Fleming– ID certificate Name: James Bond
email james@serv.com
Public Key: 1f 0a 01 15 96
9a 5a 1c cc ab 1b f1 13 e8
Expiry Date: 3/5/00
CA Name: VeriSign
CA Signature: 15 2f 36 1a
> A means of proving identity:
In Person / Digitally
> The issuer vouches for James’ Identity:
The government / a Certification Authority
> If the certificate is found authentic, James can be identified by
his:
Looks (Picture) / Digital Signature (Based on Public Key)
> Signed by: Government / the CA

6. 6
Digital Signature
> A digital signature is a small amount of data that was created
using a Private Key
> The user’s own Private Key is used to sign the data
> The user’s Public Key is used to verify that the signature was
really generated using the corresponding Private Key
> Digital signatures are used to verify that a message really
comes from the claimed sender
… assuming only the sender holds the Private Key
corresponding to the verifying Public Key)

7. 7
Features of Digital Signatures
> A digital signature should:
> Be unforgeable (convince us that Alice signed – origin of data)
> Authenticate (prevent anyone from changing the document after it has
been signed)
> Be hard to copy (remain secure even after seeing many signatures)
> Important property – non-repudiation:
> The owner of the signature cannot later deny that she signed (provides
“proof of order”)
> This is essential for electronic commerce and accountability
> Digital signatures are messages that are hashed and then encrypted
by the private key
> The private key is essential for signing
> To verify the signature, we must be sure of the Public Key owner’s
identity

8. 8
One-Way Hash Algorithms
> Reduce a variable size block of data to a small – fixed size value
called hash value
> Operate one way – the original data cannot be derived from the
hash value
> The same data will always yield the same hash value
> It is very hard to find different data blocks with the same hash value
(in reasonable time). Therefore, in reality, different data blocks will
yield different hash values.
Hashing
Algorithm
Data 100110101
Hash Value
Different
Data
011010111
Different

9. 9
Using Hash for Digital Signing
Verification
(Decryption)
Hashing
Algorithm
Signing
(Encryption)
Hashing
Algorithm
1101011011
Bob
(Sender)
Alice
(Receiver)
Plain Text Message +
Signature
Compare!
Bob’s Private
Key
Bob’s Public
Key
1101011011
1101011011

10. 10
Whom Do We Trust?
> When doing business, there has to be a body we trust to issue
certificates
> The trusted party that issues certificates to the identified entities is
the Certification Authority (CA).
> Policies ensure that every certificate applicant goes through a known procedure
that verifies his/her identity
> Policies enable clients of the CA to evaluate the amount of trust that can be
given to a digital certificate
> As a common Trusted Third Party, the CA enables two individuals to
trust each other’s authenticity
> By holding the CA’s Public Key (Root Certificate), users can validate
the signature of certified users – by trusting the authenticity of their
public keys.

11. 11
Trusting the Root Certificate
> Existing Root certificates can be view through the
Content tab in IE Tools Internet Options

12. 12
Internal CA Hierarchy
> Root CA
> Most trusted certificate
> Best security
> Least accessibility
> Others
> With distance from root
> Decreasing security
> Increasing accessibility
Accessibility Security
Root CA
Intermediate
CA1
Intermediate
CA2
End Users

13. 13
Use Case: eDocuments

14. 14
Industry Challenge:
Moving from paper to digital documents improves efficiencies for invoice processing,
storage, and retrieval while eliminating the cost and complexity of issuing and storing
large amounts of paper based invoices.
Security Challenge:
To instill confidence in eDocuments security measures must be taken to establish
trust as documents change hands, ensure document integrity, and prevent
repudiation
Role of HSMs:
HSMs are the cornerstone for establishing this trust- safeguarding the cryptographic
keys that will sign/verify the documents, providing security in the digital process, and
ensuring trust across all parties.
Benefits:
Data is secured and stored to produce electronic evidence. Relieves administrative
burden by reducing the risk of human error. Increases productivity for lower overall
costs.
Moving from Paper to Digital: eDocuments
Why are HSMs needed?

15. 15
Secure Digital Documents
Why SafeNet HSMs are the right fit for eDocument Schemes
SafeNet HSMs offer the robust security capabilities that ensure compliance
with the European Directive on Invoicing, Brazil Notal Fiscal (NF-e), and other
regulations.
SafeNet HSMs are highly secure FIPS 140-2 and Common Criteria certified
appliances capable of providing the high entropy key material required in
eDocument schemes.
Centralizing cryptographic keys and policy management on SafeNet HSMs allows
businesses to significantly reduce the administration associated with managing digital
signatures in a distributed, disparate fashion.
With a secure , high performance, eDocument system in place, organizations are
well equipped to integrate digital documents with other backend applications,
such as procurement and enterprise resource planning, which can lead to further
efficiency and accuracy gains.

16. 16
Deployment Example
The role of HSMs in secure eDocument processes

17. 17
Deployment Example
The role of HSMs in secure eDocument processes

18. 18
Sample Certificate

19. 19
Corporate Digital Sign Sample

20. 20
Digital Sign Properties

21. 21
Counter Digital Sign Sample

22. 22
Tax Invoice Sample

23. 23
Standard Document System
SMTP
eMail Server
ERP System
Receipt Printing
Staff
Automated
Billing System
Mass Printing
Standard Mail

24. 24
Smartcard
Contact, Contactless and Physical Access
Supported Solutions
> Remote access (VPN)
> Network access
> Proximity access
> Digital signing
> Data security
> Picture ID Badge
Certifications*
> FIPS 140-2 certified
> Common Criteria certified

25. 25
Digital Sign Policy System
SMTP
eMail Server
Policy System
Receipt Printing
Users Automated
Printing System
Mass Printing
Standard Mail
Traditional
Printing System

26. 26
Luna SA HSM
SafeNet Luna SA – Network Attached HSM
FIPS 140-2 Level 3 and Common Criteria EAL4+
validated
Trusted Keys in Hardware
Segregated DNS Domain key storage (100 partitions)
High Performance – 7,000 tps
Key Storage capabilities – Scale 10,000 keys/per HSM

27. 27
Automated Digital Sign Policy System
SMTP
eMail Server
Policy System
Receipt Printing
Users Automated
Printing System
Mass Printing
Standard Mail
HSM
Traditional
Printing System

28. 28
Document Signing Software
28

29. 29
PDF Signing Diagram
Policy System
eMail Server
HSM
Unsigned PDF Signed PDF
Signing Software / API Coding
Online Customer

30. 30
PDF Signing Result
30

31. 31
XML Signing Diagram 01
Policy System
eMail Server
HSM
Unsigned XML Signed XML
Signing Software / API Coding
Online Customer

32. 32
XML Signing Diagram 02
Policy System
eMail Server
HSM
Signed PDF
Signing Software / API Coding
Revenue Department
Database
Online Customer

33. 33
Unsigned XML File
33

34. 34
Signed XML File
34

35. 35
35