Generating sets of unreadable/secure and unique random numbers

In the process of some research I have been doing I stumbled across the following 2 claims on the PokerStars website.

We do record all of the hole cards in all real money hands. This is an important tool to help us investigate fraud and collusion. However, this information is not accessible to anyone until after the conclusion of the hand; it is not transmitted to our database until all action is completed and the pot has been awarded.

To be clear: Nobody in the public or employed by us can obtain information from the servers to find out the hole cards of any hand in progress. Nobody in senior management, none of the software developers, no operational representatives. Nobody at all.

This got me thinking, how would you go about writing such an algorithm?

Lets start with the following requirement:

"Generate a collection of 52 random numbers representing a deck of cards in such a way that no malicious third party could determine which cards were generated even if they had direct access to the memory of the computer generating the sequence. This sequence of encrypted numbers must be reversible but not until the completion of the game."

My first attempt at architecting a solution to this problem went along these lines:

1. A new hand begins.
2. Each client in the system generates a new public/private key pair.
3. Each client in the system makes a request for a tuple of new hole cards. With this request the client sends its public key.
4. The server receives the request for new hole cards and uses the public key provided by the client to encrypt the random numbers generated and return them to the client.
5. At the end of the hand the client sends the private key back to the server and the server can now decrypt the hand information.

Unfortunately such a implementation has a number of flaws, chief among them:

1. If the client disconnects prior to the completion of the hand the server can no longer decrypt the value that was sent to the client, given that it doesn't have the private key.
2. The requirement that a deck of cards must not contain duplicate values ensures that somewhere in memory, at some point in time you must store a collection representing the cards which have already been dealt. This completely negates the original purpose of this algorithm as this information can now be potentially read by a malicious third party who has access to the device.

If you're going to be able to log the information you need to log in the event of someone disconnecting before the end of a hand, it seems like you're going to have to be able to reconstruct that information server-side? And if sufficient information is stored server side to reconstruct the data you're trying to keep hidden before the end of a hand, then anyone with access to the server should be able to do it before the end of a hand as well - it seems like the ability to compensate for a disconnect and ability to read hidden information before a hand ends go...hand-in-hand...

Can anyone suggest a potential implementation of such an algorithm or definitively prove that such an algorithm is not possible?