The chip does have a unique private key signed by the bank, and the terminal can use that to verify that it's a genuine bank-issued chip - that's why the fraudsters needed to embed genuine chips from valid bank cards in their hacked cards. Unfortunately, due to banking industry stupidity that signed message doesn't tell the terminal whether the PIN was verified or not. It has to rely totally on an unsigned, unprotected message that can be MITMed to verify the PIN.
Actually, the card number is signed by issuer's certificate for exactly this reason. The same signed datastructure can also contain card's own public key(s) when needed by the used EMV implementation. There can be signing key that is used when card generates signed data files internally (I'll admit that I have no idea what that is good for) and second RSA encryption public key that is used for some card holder authentication mechanisms (eg. for encrypting PIN sent over cable from PIN pad to the actual terminal).
One important point in this is that nothing from this PKI mechanism is involved when the card generates the final transaction signature (called "Transaction Certificate" by EMV). Standard does not specify mandatory algorithm for that and also such algorithm necessarily has to be some kind of truncated symmetric MAC, as the resulting value has to fit into 32 bits (and ideally contain only BCD nibbles). There are some recommendations about what algorithms can be used for that in the standard also with recommendations about key management for the symmetric part.
The MitM essentially has no idea about EMV whatsoever and only traps one command and returns fixed OK response. Due to way how the card holder verification process works this results in terminal thinking that the entered pin was correct, while card thinks that no PIN was required for transaction (the idea there is that terminal and card calculates what verification methods they deem sufficient depending on various parameters of transaction and their internal state). While these two states are obviously different, they are encoded by same binary pattern in transaction flags (there is bit that means "verification failed" and nothing that encodes whether the verification was attempted or even what method was selected) and thus the terminal's view of transaction matches the signature generated by card.
Interesting point in this is that the card usually allows the transaction even without the verification succeeding. Idea behind this is that the transaction can be downgraded to card+signature by the terminal for various reasons (standard specifies list of some reason codes that contains reasonable things like "hardware problem with keyboard" but also "cardholder does not know the PIN").
In it's entirety the protocol is designed not to be absolutely secure, but to be efficient, reliable and provide usable audit trail for later review that is usable to unequivocally assign blame for disputed transactions. Essentially only problems with EMV from security standpoint come from complexity that is motivated by the reliability and backward compatibility requirements.
By the way there are certainly better workarounds for this vulnerability that testing whether card with no selected application responds to pin verification command that can be implemented on the card side, but they reduce reliability (eg. disallowing offline PIN verification, disallowing transactions without cardholder verification...). On the other hand these workarounds really solve the issue, while testing from protocol peculiarities by the terminal can be worked around by the attacker by implementing better MitM chip that tracks state of the original chip.
Arm's race between phone companies and phreakers who emulated payphone EPROM chipcards that involved things like the phone measuring various impedances of the card pins and finally ended with deprecating the whole thing (either by migrating to true smartcards or by simply discontinuing the cards, or even payphones) should be enough to convince anyone that authenticating devices by means of implementation details only slows the attacker down.
