I am quite familiar with most of the common undergrad/grad security foundations; but I couldn't find anything related to this scenario:
A scheme/system where a piece of data can only be 'decrypted' AND read only once (potentially in a computer program).
Is it even possible? I have heard such things are there in the 'hardware world' (?). If my question is imprecise/incomplete, I'm willing to update. But I am actually interested in a generic design/protocol at the same time.
There is no way to do this - this is a subset of what DRM schemes attempt to do.
If an end user can decrypt something once to see it, they can see it again. Any of the following may be possible:
The only way you could get close would be to have total control over the hardware and software, so you could delete once it has been shown, but even then, someone could use a camera to take pictures of the screen etc.
So, I'd like instead to ask what you intend to use such a scheme for - as there are ways to have the same effect in many scenarios.
As you already hinted at, such a thing is only possible in hardware. A software or encrypted data solution would always suffer from the option of making a copy before decryption.
In hardware, the scheme would be to destroy information on decryption. A naive approach would be to simply read a block into memory, destroy it on storage and then decrypt it.
That approach, of course, can fall victim to tampering - an attacker could manipulate the system so that the deletion fails, but whatever is doing the decryption believes it succeeded and so proceeds with decryption.
A more sophisticated approach would be to exploit some physical property in such a way that reading the information also destroys it. This is, in fact, what makes the largely theoretical quantum cryptography secure - you cannot eavesdrop (listen in) without destroying information, thus revealing the fact that someone is intercepting the message.
Outside of the quantum realm, there might be solutions using chemical or other physical processes, but they will also be subject to tampering.
If a network is available, you could offload the decryption procedure (and the private key) to a service running on a secure server. You could then enforce whatever rules you want on the server.
The client would submit the opaque text to the service and ask it to decrypt it and return the plaintext content, and the server could decide whether the client should be allowed based on decryption history-- potentially blocking more than one decryption operation.
However there would be nothing preventing the caller from using the result of the decryption over and over, which is more or less the same as decrypting it over and over. There have been attempts to do so for music and movies (see protected media path) but it's a losing battle. If nothing else, a hacker could spoof the monitor hardware and record the input signal, or even just point an HD video camera at the monitor and record the content as it plays. A similar interception technique could be used for any sort of digital content. So the bottom line is... not, it's not really possible.
A more feasible approach would be to bake a serial number into the content itself and track it in an authorization server, or to bake in an expiration timestamp. You'd then need to enforce this on the receiving end, which would have to be a secure application. This is how a one-time password works, for example. But that requires you to own both ends of the data path and for the data itself to be useless outside of it.
It is not in any way practical, and fundamentally impossible (in a reliable way), but it may be possible to some extent.
The obvious hindrance which makes the endeavour fundamentally impossible is that whatever it is you decrypt, once you've read it, it's inside your head. So, to be sure the secret stays secret, there would have to be a poison pill mechanism of sorts. Maybe a capsule that contains a TTS engine and transmits the message to you via bone conduction, and then explodes, blowing off your head.
Because, you know, as long as you breathe, you can just tell someone. Still, let's hope you don't repeat aloud what the TTS is whispering in your head.
That aside, there exist data storage systems which can be read only once. DRAM and Ferroelectric RAM as a non-volatile alternative are two examples of that. These need either an explicit write-after-read built-in, or something different (e.g. capacitator circuit). Otherwise, reading the information destroys the information. Leave that out, and you have gone forward a big step.
Now, at the very least, one would have to make two copies (one onto a non-destructive-read storage, and then another one to actually have a copy). Still, that's quite within the realm of "doable", but depending on hardware compatibility it may be somewhat of a burden anyway (not sure you can just wire up two entirely different, incompatible storage types and copy data like in Star Trek, might very well be that it proves a bit more difficult than that!). But we're not at the end.
The decryption key, and even part of, or the complete the decryption executable (assuming loops are unrolled) might as well be stored on destructive-read storage inside the decryption hardware. The decryption key does not ever need to leave the chip, so other than for "data", there need to be no lanes for transmitting it. It's read during decryption, and after that it's gone. So... there you go.
Unless you assume someone might drill holes the size of a few dozen nanometers into the chip and use nano-wires to somehow wiretap into the storage, there's no way of getting to the data. I'm not saying this is impossible, just... that it's kinda crazy. No information is valuable enough to warrant that. Plus, I'd guess it might be a quite risky procedure since accidentially leaking a tiny charge or going a few nanometers too far left or right will inevitably destroy the key, too.
As the decryption key is usually very small (32 bytes or less), it could in fact be stored inside a secure enclave processor or similar, as is done in many mobile devices routinely nowadays. That storage could also have destructive reads (and no external access to enclaved data, much like on every modern phone). But it doesn't even need to.
You could have fuses such as in Samsung's Knox or Apple's SEP, which in principle allow you to decrypt the data N times (not just exactly once, but exactly N times, as many as you like). After that, the processor simply doesn't refresh (or explicitly overwrites) the key. Or, much less secure (but probably still good enough), it only refuses to decrypt.
Thus, making a copy of the encrypted data really won't do much good because you cannot decrypt the copy.
Of course, someone can still trivially copy the decrypted data, if there are any means of doing so. Usually there are, both digital and analog. If nothing else, you can have two or three people looking at the screen simultaneously, or take a photo.
That, however, is a problem that you just fundamentally cannot solve (except by an exploding device, or a device releasing nerve gas).
From a purely theoretical sense - it is only possible if you can make sure that after the first decrypt there are no copies in existence of both
In principle, you can only do this with the cooperation (willing or coerced) of the parties that handle these pieces of information that need to be deleted.
In practice, this can be enough depending on what you want to achieve, and what components of the system you are willing to trust.
For example, if you trust a typical iPhone (you shouldn't, in the absolute sense, but like all things in security, there are few absolutes, there is usually only probability and how much risk you are willing to accept), you could choose to assume that an iPhone app you wrote and its data cannot be tampered with by either malware or the human user, because that's the sort of thing Apple seems to try to ensure, and thus you can do decryption and make sure to delete the data in your code after.
(You can always imagine a meticulously secured and audited device that you made yourself if the iPhone feels too insecure or untrustworthy for you.)
This does not remove the "analog hole" if you are showing that data to the user or otherwise leaking it in an observable way, but that might be acceptable for some usecases - for example maybe you are not showing it to the user, but only using the decrypted data as part of some security scheme in the implementation details that the user does not directly need to see.
We can extend this example to data transmission: you could send the encrypted data through one data channel, the key through another, and so long as you trust at least one of those channels to be secure and to not retain the data passed through it, or you can trust that any middle-men who can eavesdrop on one channel will never be able to pass information with any who can eavesdrop on the other, then you have a decent guarantee that the only thing that ever decrypts it is your cooperating client code.
TL;DR: If you understand why it there is no perfect solution to this problem in principle, you can identify some situations where you can achieve it with high enough odds to be comfortable in practice. But those situations might not overlap with what you were hoping to do.
This is one of the promises of quantum communication - in theory, since observation fundamentally alters quantum states, it would be possible to create a "read once" communication protocol.
Of course, practical problems like "user can still take a picture of their screen with their phone" still remain.
