Re: [ekmi-implementation] Groups - EKMI Implementation & OperationsGuidelines (SKMS DRAFT)

[Tomas Gustavsson <tomas@primekey.se>]

Thanks for the good response Arshad.

Just a few additional comments...in-line.

Cheers,
Tomas


Arshad Noor wrote:
> I apologize for the long delay in responding to your comments, Tomas,
> but I've finally started catching up with my work after that long
> trip.  Thank you for your patience.
> 
> Please see my comments below, inline within your message.
> 
> Arshad
> 
> Tomas Gustavsson wrote:
> 
>>
>> Hi Arshad, I have read through the new EKMI guidelines (your part 
>> off-course not mine :-)). Well written as usual and it reads very 
>> fluently.
> 
> 
>     Thank you.
> 
>> Here are my comments.
>>
>> In the introduction you you mention breaching sensitive information of 
>> millions of US-based residents. I don't think this is a US-specific 
>> issue, but rather a global one.
>>
>     I agree.  The UK breach of 25M people last month is a telling
>     example of the global problem.  If you have any other examples
>     of breaches in other EU/Asian countries, I would appreciate
>     hearing of these.  In the meantime, I've corrected this section.
> 
>> Page 1: srever -> server
> 
> 
>     Fixed.
> 
>>
>> In 3.1 you say that the encrypted CCN and the decryption key must be 
>> available to store employees. I am under the impression that the store 
>> employees should never see the CCN, after all they are the most likely 
>> to commit fraud. At the swedish post only support representatives 
>> through the back office systems can decrypt the CCN, never out in the 
>> store.
> 
> 
>     In principle, I agree with you.  But, whether the store
>     employees see the CCN or not would be upto the business
>     application and policies.
> 
>     What I should have said is that "the key must be accessible to
>     authorized applications - which are used by authenticated users    
>     - which are authorized to retrieve the symmetric key to decrypt
>     sensitive data within controlled environments".
> 
>     Ultimately, only applications really have access to symmetric
>     keys - individual human-beings do not.  However, once human
>     beings are authenticated to applications, and if the credential
>     of that human-being (or the POS register, or application) is
>     authorized to retrieve the key, then the SKS server will
>     retrieve and send the key to the application.
> 
>     In the feedback that Sandi Rood (US DoD) provided the TC on the
>     SKSML protocol, one of the business requirements she made was
>     that the protocol should accomodate policies that specify which
>     applications may use the key.  Additonally, the Singapore DoD
>     requested that the protocol should accomodate where the key may
>     be used (specific GPS location), when it may be used, etc.
> 
>     I am planning to update the SKSML to accomodate these requests
>     and will be sending out the update this month.  So, the protocol
>     will take these things into consideration and will ensure that
>     even authorized human-beings will only be able to use the key
>     within controlled environments.
> 
>     I will update this section in V2 of this DRAFT document.
> 
>>
>> Under corporate you mention that the SKSML protocol allows for secure 
>> caching of symmetric keys. Technically the protocol does not 
>> off-course provide security for the caching mechanism. Perhaps it 
>> should be mentioned somewhere how caching should be made securely? The 
>> guildelines could impose some requirements on the caching.
> 
> 
>     I should probably elaborate how the protocol does provide for a
>     secure cache, Tomas.
> 
>     SKSML, as you know, is a SOAP-based protocol that uses Web
>     Services Security (WSS) to protect the contents of the message
>     via a digital signature in the header and encrypted payloads.
>     (The SOAP layer could also encrypt the SOAP-Body, but in the
>     StrongKey configuration I have turned it off since the payload
>     is already encrypted by the SKS server.  So, the encryption in
>     the SOAP-Header is superfluous).
> 
>     The way StrongKey manages the cache is that the Symmetric Key
>     Client Library (SKCL) - which is responsible for all SKMS work -
>     receives the SOAP response from the SKS server, and immediately
>     writes the response to the cache directory.
> 
>     If caching is turned on - through a KeyCachePolicy - then the
>     SKCL manages this key using the KCP parameters.  If caching is
>     not turned on, the SKCL deletes the key after using it.
> 
>     However, since the SKSML response is saved in the cache in the
>     precise format that was sent by the server, it is already
>     encrypted (in the SOAP-Body) and digitally signed (in the SOAP-
>     Header).  Each time the SKCL retrieves this key from the cache,
>     it verifies the digital signature and then decrypts the payload
>     using the Private Key authorized for use by the SKCL.
> 
>     This is what I meant by the SKSML allowing for secure caching
>     for keys.  While the SKCL is responsible for actually persisting
>     the key and managing the cache, because we are doing nothing
>     different from what SKSML already does for its security during
>     transport, in effect, SKSML does enable secure caching of the
>     keys.
> 
>     Does that explain what I meant?  I will update the document
>     to reflect this.

Very good. That is probably sufficiently secure caching. It is more that 
the StrongKey SKCL provides for secure caching though, using the 
features of the protocol (i.e. caching the secured soap message).
Since it's a standard protocol any other SKCL than StrongKey could 
off-course be used, in which case what you just wrote above would be a 
good recommendation for it's caching.

>> In the architecture you have a primary and a DR data center. Is a DR 
>> data center really common for medium sized enterprises in the US? In 
>> sweden a separate DR data center is surely only used by the largest 
>> corporations. Medium sized I think are satisfied with off-site backups 
>> and disastar recovery plans.
>>
>     You are probably right, Tomas.  Whether a medium-sized company
>     has a live DR center or an off-site backup with a DR plan, is
>     really a function of the risk-tolerance of the company.
> 
>     I will modify the architecture to accomodate for both options.
>     I will also point out that if there is no live DR data-center,
>     then the implementers must ensure that their KeyCachePolicy
>     takes into consideration the amount of time it will take IT
>     Operations to recover the SKS server, so that SKMS clients can
>     continue operating with cached-keys for that duration.
> 
>> 3.3.1 Best practice policies:
>> When a transaction based key-validity is used it puts a burden on the 
>> client to crach-safely store a transaction counter. 
> 
> 
>     I agree with you; the burden is on the client - actually, on the
>     SKCL since it is the SKCL that will be doing the caching.  But,
>     you're right - it is on the client.
> 
> Did you ever think
> 
>> about a server record for transaction counting to be able to expire a 
>> key for encryption by all clients?
> 
> 
>     I did.  However, managing that policy on the server is far more
>     problematic because it will depend on continuous network
>     availability to do it correctly.  If clients cannot communicate
>     with the server to update the counter, they may individually
>     stay within the policy but collectively violate it.
> 
>     Thats why I decided to let the client take sole responsibility
>     for managing the counter.  I guard against the possibility of
>     collectively violating the transaction-based KeyUsePolicy (KUP)
>     by making sure that the SKCL never uses an *existing* symmetric
>     key that it receives from the server for encrypting *new*
>     transactions.  It uses existing keys only from the local cache
>     for encrypting new transactions, and only if the KUP allows it.
>     Otherwise, the client always gets a new key from the server.

I think this is very good too. The same principe though, that it would 
be a good recommendation for any other SKCL implementation, or perhaps 
more for auditor to check that the SKCL in question works securely.


>> For the caching policy I think a number of days for caching is too low 
>> resolution. I would prefer 'Maximum New Seconds' and 'Maximum Used 
>> Seconds'.
> 
> 
>     This is an interesting statement.  The business requirements I
>     heard from retailers is that they need to cache keys for weeks,
>     if not a few months, on the POS registers.  However, the KUP
>     metric can be easily changed to reflect seconds instead of days.
>     Days can be much more easily represented in integers using
>     seconds, than to have seconds represented in days using
>     decimals. :-)

Very much so, seconds is prefferred  :-)

> 
>> The 'Use First' flag is redundant so I don't see the need for it? I 
>> can understand the convenience of an explicit flag, but redundance 
>> should generally be avoided.
>>
>     Excellent point.  I will remove this in the SKSML spec when
>     I update it.
> 
>> Should we add some recommended values to this best practice policy?
> 
> 
>     Hard to tell, Tomas.  It really depends on the business
>     requirements of the companies deploying the SKMS.  Perhaps, TC
>     members within specific sectors - Finance, Health, Defense,
>     Retail, etc. - can provide some suggestions on this?
>     
> 
>>
>> 3.4 Security considerations:
>> Is point g) really nessecary if point b) is implemented?
> 
> 
>     In many PKIs I have built, the people who have physical access
>     to the room with the HSM, do not have access to the credentials
>     that control the M of N access - i.e. they are not part of N.
>     That is why I explicitly called out both requirements here.
> 
>     Are implementations of PKIs done a little differently in your
>     experience, Tomas?  Do any of the other TC members with PKI
>     Operations experience want to chime in here?
> 
>> Point j) is not mentioned anywhere. It is quite implementation 
>> specific. Perhaps a recommendation that the implementation should 
>> encrypt and/or digitally sign all database records. If the database 
>> records are not encrypted, security controls for the backup is needed.
> 
> 
>     While I first thought that this should be an implementation-
>     specific feature, I changed my mind and later decided to make
>     it a baseline feature, Tomas.
> 
>     We are creating a new paradigm for security here that will,
>     hopefully, last a very long time Tomas.  It would be better to
>     do this right the first time, rather than have business
>     customers realize later on that even though they saw the
>     OASIS-standard checkmark on the vendor's data-sheet, their
>     implementation that supports SKSML does not provide the same
>     level of security as others.  What good would the standard be?
> 
>     I think we will be doing the industry and the business-community
>      a favor by making digital signatures of the database records a
>     baseline security recommendation.  Given all the work that the
>     SKS server is doing (it MUST encrypt the symmetric key
>     regardless of whether the database record is digitally signed
>     or not), digitally signing the record in the database and
>     verifying it eliminates attacks on the integrity of the data,
>     and moves the focus to the protection of the Signing Key on the
>     server.
> 
>     I am starting to see a very good business reason why more
>     applications need to digitally sign their database records (at
>     least for e-commerce applications).  At a recent project for an
>     e-commerce vendor, I pointed out to them that an attacker -
>     external or malicious insider - could easily take control of
>     the entire e-commerce site by replacing the e-mail addresses
>     and password fields of customers using SQL.  Legitimate
>     customers would never get any e-mail for password-reset requests
>     thus locking them out of their accounts.  Most e-commerce sites
>     do not provide telephone access, and even if they did, how would
>     they authenticate the caller on the phone?
> 
>     Given the state of the internet today, I think it would be
>     better to err on the side of caution.
> 
>> Point l) i guess should be moved to the PKI section actually.
>>
>     While we can mention it in the PKI section too, this specific
>     guideline does belong here.
> 
>     The reason is: companies deploying a PKI might choose to deploy
>     a Closed or an Open PKI.  But, the guideline is, if they are
>     planning to use their PKI for operating an SKMS, then they
>     should make sure that they are using a Closed PKI for the SKMS
>     regardless of what they do for other applications.
> 
>> At least some input to your hard work.
>>
>     THANK YOU, Tomas!  Your suggestions and comments are extremely
>     thoughtful and valuable.  I now have to rewrite the IG to
>     reflect your comments, AND provide you feedback on your PKI
>     section (my apologies for my inexcusable delay).  Hopefully, I
>     can get to completing both before the end of the month.
> 
> 
>> Regards,
>> Tomas