I'm having trouble understanding the high-level security architecture of the GlobalPlatform Card specifications, specifically the capabilities of the card issuer and the Issuer Security Domain.
Can the card issuer actually access the private data of an installed application, or is that something that should not be possible?
In other words, is having the Card Issuer keys comparable to having full system privileges on a card, or is it limited to installing new and deleting installed applications, creating Secure Channels, disabling the card etc.?
(This is quite a complex question and the "answer" below is just my personal opinion in the java card context -- no MULTOS)
The ISD keys (card issuer keys) protect the access to the services of the ISD. There is no service which allows reading any private data of an installed applet (application), thus the simple answer is "No".
Unfortunately the ability to install any applet opens the door for further attacks (like having code execution under an unprivileged user account increases the attack surface on any "standard" computing system).
Several attacks using malicious applet were already published and probably there are more yet to come, so the responsible answer is "There is some risk involved".
Some additional random notes:
the ISD keys allow access to the Global PIN
(AFAIK) any applet can access other applet's static methods/fields at will. The application firewall does not protect them
in the simplest cases, the ISD keys allow impersonating other applets (when there is no applet authentication in place) -- on APDU and Shareable levels
[assuming SCP(01/02/03)]: if an attacker has the ISD keys and is able to obtain APDU logs of any communication protected by this keys (even if the confidentiality secure messaging mode is used) then he is able to decrypt this communication (e.g. having the card personalization APDU logs + security keys = having all the secrets which were sent to the card during the personalization). There are some quite impractical precautions which might be used (e.g. loading secrets under an on-card generated RSA public key)