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

[Arshad Noor <arshad.noor@strongauth.com>]

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.
> 
> 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.

> 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. :-)

> 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