Anton Krupskyi security analyst Accenture Latvia https://dssitsec.eu

1. 1
The futureof PKI.
Usingautomationtoolsandprotocolstobootstraptrustina dynamicenvironment
Anton Krupskyi
October25th,2018

2. 2
AGENDA
Problem
End-to-end encryption in
dynamic cloud software-
defined infrastructure
Solution
Automated certificate
lifecycle management
Implementation
Design, Tools and
Mechanisms used

3. 3
THE SITUATION
 Separatenetworks in every
country
 Individual services and productsfor
every market
 Traditional hardware platforms
 Around 650 service platforms

4. 4
THE SOLUTION
 A single unified network
 Modular services to cater to
different market requirements
 Agile infrastructure cloud, based on
virtualization and software
defined networks
 Agile datacentres
 End-to-end encryption

5. 5
 Data transmitted on networks can be
intercepted
 Agencies like the NSA and motivated
criminals use surveillance technology to gain
information
 To protect ourselves and our clients, we need
to use encryption
DESIGN PRINCIPLE:END TO END ENCRYPTION
TheSolution: Public Key Infrastructure
 State-of-the-art encryption algorithms
 End-to-end encryption between all machines
 Trust anchors

6. 6
Asymmetric encryption
 Uses pairs of public and private keys.
 A message encrypted by one key can only be
decrypted by the other.
 Users publish their public keys and keep the
private key secret.
CORNERSTONES OF A PUBLIC KEY INFRASTRUCTURE
Trust & Identity
 A certificate links a public key to an identity.
 The certificate is provided by an authority that we
trust.
 The certificate authority verifies the identity of the
public key before issuing the certificate.
We can think of the
public key as a
mailbox and the
private key as the
key to the mailbox
The mailbox now has
an ID that assures us
that the owner is
indeed who we want to
contact

7. 7
 Encryption relies on the secrecy &
trustworthiness of the key
 Communication partners exchange public keys
when establishing a connection
 Without certificates, malicious 3rd parties
could intercept the key exchange and
substitute their own key
 A Certificate Authority provides us with the
means to verify a chain of trust
 The CA signs a server’s public key after it
proves its identity
 If we trust the CA, we can trust the website that
has the certificate
THE CERTIFICATE AUTHORITY AS TRUST ANCHOR

8. 8
 Infrastructure or service owners need to
enroll their services to receive a certificate
 This is typically done in a manual
verification process to prove legitimacy and
ownership
 Same process needs to be repeated
periodically to renew certificates
 This process does not scale
in cloud environment
AUTOMATION & CLOUD
Challenge
 Certificate distribution in a dynamic,
highly distributed environment
 Distribute certificates quickly to new
machines when scaling out
 Remove need for manual certificate
lifecycle management
 Short certificate lifetime

9. 9
 CA provides certificates to services after
verifying their Identity
 Using a dedicated client, a service can
automate the verification and the certificate
lifecycle
 Using the CLIENT with configuration
management tool, deployment of the client
and requesting a certificate can be fully
automated
AUTOMATED CERTIFICATE DISTRIBUTION
Solution
 Challenge response mechanism
between client and CA
 Certificate lifecycle management through
automated client

10. 10
THE ACME PROTOCOL
Created bytheInternet Security
Research Group forLet’s Encrypt
Their goal: Increase usage
of https over http by
making certificates free and
easy to obtain
Automatesinteraction between
Certificate Authorityandclients
No manual steps
necessary to receive
certificate
Certificate lifecycle is fully
automated
Does not sacrificesecurity over
convenience
Client and server perform
the necessary steps for a
full domain name validation

11. • Boulder is a CA that implements
the ACME protocol and can
communicate with Certbot
• Certbot is a client that can
automatically fulfill validation
challenges
• Certbot also takes care of
certificate lifecycle management
11
THE ACME PROTOCOL
BoulderCA andCertbot are theLet’s Encryptimplementations ofthe ACMEprotocol
Certificate signing
request
Validation challenge
Challenge response
Signed certificate

12. 12
VALIDATION CHALLENGES
• The ACME protocolandBoulderCA
offerthreedifferentwaysto prove
ownershipofadomain
• Forall challenges,
the CA providesa token
• The tokenis anoncethatuniquely
identifies thechallenge withatleast
128bitsof entropy
HTTP Challenge
• Client creates ad-
hoc webserver
• Client places file at
specific address on
the webserver
• File contains token
TLS-SNI
Challenge
• Client creates TLS
server with custom
vhost
• CA creates TLS
connection to client
and uses SNI
extension to request
the custom vhost
• Client provides self-
signed certificate
containing the token
in the SAN field
DNS Challenge
• Client provisions a
txt source record for
the domain at the
DNS server
• This record contains
a SHA256 digest of
the token
• Not automated at
this point

13. 13
WHAT YOU GET
Transparent end-to-endencryption
Every device has a
private/public key pair and
a certificate to identify itself
Automatedcertificatedeployment
Receiving a certificate is as
easy as adding few lines to
server configuration tool
Managedlife-cycle/
ease ofuse
The lifecycle functions of
the client are also
automated, removing the
need for manual renewal

14. 14
USE-CASES
BoulderCA
(PKI-CA)
 Can perform
automated
validation
 Signs service
certificates for
identification
and encryption
ManualCA
 For services
that do not
support
automation
 Signs service
certificates for
identification
and encryption
UserCertCA
 SSL certificate
for user
authentication
 S/MIME
certificate for
email
encryption &
signature
 Certificate for
document/code
signing
EndpointCertCA
 802.1x
certificate for
access
management
between
devices &
within network
 EFS endpoint
encryption
SmartCardCertCA
 Two-factor
authentication
 Physical
access control
 Future use-
case: Payment
option

15. 15
ARCHITECTURE OF OURPKI
UserCertCA EndpointCertCA SmartCardCertCA
RootCA
BoulderCA
PKI-CA
CertBot
PKI-CLIENT
ManualCA
signed
Signed manually offline
InfrastructureCA UserCA
Signed manually offline
signed signedsignedsigned
signed signed signed signed
Automation
Manualverification
EndpointUser SmartCard

16. 16
HIGH AVAILABILITY BOULDERCA SETUP
Service with
Certbot
Boulder 1
Soft-
HSM
HAProxy
LB
GALERA
BoulderCA SetupInternal
Services
DNS LB
Boulder 2
Soft-
HSM
Boulder n
Soft-
HSM
scales out
PKI-CLIENT
HAProxy
LB
PKI-CA

17. 17
BOULDER CA INTERNAL ARCHITECTURE
Storage
Authority
Web Front-
End
Validation
Authority
Registration
Authority
Certificate
Authority
Soft-HSM
MariaDB
OCSP
Updater
OCSP
Responder
Certbot
Service/
Client
BoulderCA
 Tasks split between
separate components
 Standard deployment
straight from GitHub:
Docker containers
• Boulder
• MariaDB
• Soft-HSM

18. Automation and
Virtualization
SecurityContinuous
Integration
Open Source
Software
18
ENVIRONMENT, TOOLS AND DESIGN PRINCIPLES
 Infrastructure as code
 Reproducible,
automated
infrastructure
deployment
 Automated software
deployment and
configuration
 End-to-end encryption
of all communication
 Certificates with full
chain of trust
 Automated certificate
deployment
 Automatically deploy
all changes to the
development &
production
environments
 Pan Net relies entirely
on open source
software solutions

19. 19
WHO WE ARE
Diverse set of skills,
from PKI to automation
6 People
from Germany,
Switzerland and Latvia
Fully embedded
Working as one team

20. Q&A Thank You!
Contact Latvia.SecurityST@accenture.com