EMC ControlCenter 6.1 F293.8.2.12 – Security Key Management

1. EMC ControlCenter 6.1F293.8.2.12 – Security Key Management Vanessa Fage Sr. Software Quality Engineer

2. Agenda • Why Key Management is needed • Primer on how trust is established • Changes made to support Key Mgmt in 6.1 • Flow of operations • Where to find the keys in 6.1

3. Key Management Aids in Establishing Trust • Why do we need encryption? • Compliance with PSP • Network traffic is a huge security hole • SSL provides authentication • What role does trust play? • Telling someone a secret doesn’t make sense unless you trust them • Need to figure out a method of trusting someone

4. Public & private keys Mathematically related to each other, but not to machine/component Private key only known to you; Public key available to everyone Data encrypted with one can only be decrypted by the other Public key gets signed by Certificate Authority (CA) Certificate Authority Trusted third party Issues certificates to entities after their identities have been verified Bob and Alice trust each other because they trust a third party (CA) Click here for an elaborate example/explanation CA Establishing Trust

5. Architecture • KMS Server = CA • ECC Server = CA Proxy • Other components (RKMC) • Repository/DSS • Console / Store / API Server • Agents • PM Thick Client • PM Web Reports • STS • API Clients (i.e. WebConsole) • Where stored • Wallet • Lockbox • Keystore • On-disk

6. Technologies Used for Implementation • Java Components use RSA BSAFE Crypto-J library to generate keys • Covers Server, Store, Console, API Server, Tomcat, StorageScope, PM Web Reports • C Components use OpenSSL • Covers Agents and Performance Manager • ECC Repository and StorageScope Repository use Oracle Wallet to generate keys • All components rely on RSA BSAFE Cert-J library to obtain their certificates • Key Management Server uses Cert-J to issue certificates

7. Install & Trust Workflow • Install • Key Management Server installed on Repository host • Server component is installed next • “Trust_All” filter set by default in ECCSecurityConfig.properties on Server host • Customers advised to shut this off after installing all other components but before starting them up • Before doing that, a trusted Console should be installed and launched • Start Console and trust components • Start ECC components (Store / API Server / STS / etc) • They start up in ‘Neutral’ trust status • Will stay ‘Neutral’ until marked as trusted • If component stays in ‘Neutral’ status long enough, it will timeout waiting for trusted state & will stop • Appear in the console as “Agents” • Must be trusted via ‘Trust Manager’ dialog in order to work properly • Accessible via ‘Security’ -> ‘Manage Trust Status…’

8. New Utilities for Key Management • TrustedEntity utility • Used to alternatively trust component(s) at a given IP address • Supports IPv4 and IPv6 formats • Located at C:\ECC\tools\utils\TrustedEntityUtil on Server host • Designed to be used when ECC Server is unavailable • If ECC Server is up when utility is used, it must be rebooted for changes to be persisted and reflected in console • TrustStatusExport utility • Provides a report of trust status modifications made to hosts/agents via the Trust Management dialog or the TrustedEntity utility • Located at C:\ECC\tools\utils\TrustStatusExport on Server host

9. Console changes to support Key Management • Several ECC components now appear as “Agents” in Console • API Client** (i.e. WebConsole) • API Server • Console • Performance Manager Client** • StorageScope Repository** • Tomcat** • Web Application** (i.e. StorageScope, PM Web Reports) • Note: All components marked with ** will show up in the console with a “question mark” overlay, as in this screenshot • This is because their trust status can never be computed since they don’t communicate with the ECC Server via SST • Components now appear in console so that Security Admin can update their trust status via Trust Manager dialog/ TrustedEntity utility • Untrusted components appear with an overlay like this: • “Untrusted” components cannot receive Trust certificate and cannot communicate with ECC infra • The instructions for untrusting a component once it’s already been trusted are located in the “Security” chapter of the ECC 6.1 Administrators Guide

10. Trust Management Dialog

11. Trust Management Dialog - Filter

12. A few more things… • ECC Server host is trusted by default • All components installed on Server host are inherently trusted; their status cannot be modified • When to use the ‘Neutral’ status: • If you want to individually control the trust state of all agents/components on a host, then set the host to Neutral • You can subsequently set the trust state of all components on that host • The “trust certificate” (the CA cert) used in ECC is set to expire in 7 years • All components including ECC Server are signed using it • This means in 7 years the components cannot communicate! • If the Trust Certificate ever needs to be regenerated and redistributed to all components, the steps are covered in the “Security” chapter of the ECC 6.1 Administrators Guide

13. Implementation Cheat Sheet, Page 1

14. Implementation Cheat Sheet, Page 2