SCP03 - Does it always to depend on pre-provisioned static keys? I am trying to understand Secure Channel Protocol 03 from specified by Global Platform and have seen a few implementations. From the standard:


  Session keys are generated to ensure that a different set of keys is used for each Secure Channel Session. The session keys are derived from the static Secure Channel keys.


"
From what i have understood, there is a set of keys known to both parties (host and the card) refered as " static Secure Channel keys". So any new session is encrypted with a new set of keys that are freshly derived from the static keys but those keys are always derived from the same static keys.

Isn't this a security vulnerability ? I mean wouldn't doing asymmetric channel encryption like Diffie-Hellman for every session and continuing  with symmetric encryption there on be a lot better ? 

I am relatively new to the field and might be missing something fundamental or this might be an affordable risk compared to the overhead and implementation complexity. Any clarification is appriciated.
A few words on SCP03

As you said, SCP03 is based on the shared knowledge of some symmetric keys (refereed as static keys). This can be seen as a weakness more than a vulnerability since deriving multiple keys from common materials does not break the security guarantees offered by the protocol. 

For each sessions, new keys are derived based on:


The shared static keys, 
Some constants defining the length and usage of the key,
The session random challenges, one challenge generated by each peers. Each of the challenge is 8 or 16 bytes long (depending on the mode chosen by the Off-Card Entity), avoiding key collision.


In case of pseudo-random challenge generation (i.e not random), a 3-bytes counter is held on the card and involved in the generation process (only card-side). One counter is bind to a key set (i.e. a static shared keys collection), and the counter is is set to 0 whenever the key set is updated.

At each challenge generation, the counter is incremented and one. Once it take the maximum value, the card will refuse to generate a new challenge, making it impossible to complete a SCP03 session. This means that the session key set can only be used in a limited number of sessions, hence it can only be used to generate a finite number ($2^{24}$) of session key sets.

As a side note, the card send the counter to the Off-Card Entity as part of its response to the INITIALIZE UPDATE APDU, but it is not involved in the Off-Card entity side of the generation.

Asymmetric based SCP

Relying on public key cryptography, with a Diffie-Hellman-like scheme would be a better choice since it would namely:


Make key management more straightforward (no sharing)
Ensure forward secrecy


Due to the constraint of such an asymmetric scheme (PKI, large key storage, heavy computational cost), symmetric cryptography has been favored in a first time (SCP01, SCP02, SCP03). For long, RSA have not been available at all on smart cards.
As for today, the trend is slowly changing: GlobalPlatform has issued SCP10 (see the card specification, Appendix F) and SCP11 (see Amendement F) relying on RSA and ECC respectively. They both allow authentication and key exchange, before continuing with symmetric cryptography to communicate.

Smart card industry is a very slow-paced world when it comes to upgrade since deployed hardware can't be upgraded (usually). To give you an idea, SCP03 took almost 8 years to be implemented and deployed, despite its similarities to the widely deployed SCP02, and you can still find a lot of SCP02 in the wild, even so it is  has been shown to be vulnerable to some attacks.

Some say that SCP10 will be skipped altogether, and the SCP11 will be used instead, but RSA is more widely supported. 
That being said, I couldn't manage to find any SCP10 or SCP11 open source implementation.