- What's the principle to design the functionality, if it aims to a new scene that Canetti hasn't treated? Are the ability to corrupt parties (by some unknown methods) required to be written into the functionality? What else (except the normal functions) should be written into it?
Basically, you can design the ideal functionality as you wish. The functionality does not consider corruption, because it is the ideal version. In order to make it more clear, you can consider the functionality as a trusted third party, which takes all the necessary input from all parties, computes the result and outputs it to those parties who should receive it.
- It is required that the simulator must successfully deal with any adversary. So how to 'predict' the behavior of adversaries if there are some abilities of adversaries which are not listed in the functionality?
UC is one of the strongest framework to proof security, because it does not give the adversary explicitly any power. In fact, in UC proofs the real world adversary is mostly just a dummy adversary, who just forwards any message it receives to the environment.
What happens is that you give the simulator some advantage (otherwise it would never work) e.g being able to choose the CRS, extract witnesses, etc.. And then you have to proof that the environment can't distinguish between real and ideal.
- What will happen if I write an only seem-to-be-right functionality?
Well, you prove that the protocol is a secure zealization of your functionality. If the functionality is "wrong" (not what you intended actually), then you have nothing.
- Why do real protocols mostly ignore the message type field (as new-session, test-password, ...) used in functionalities?
An example for that would be great, as it is not really clear what you mean. Sometimes, session IDs, etc. are omitted because they just blow up the length of the descriptions/proofs, making it unnecessary complex to follow.
- Does the environment gives some inputs to the simulator? Does the simulator need to simulate any non-corrupted parties? What information can be got by simulator?
Simulators replace corrupted parties. If the environment can give some input to a normal party and it is corrupted, the simulator has to do exactly the same in the ideal world. The difference is: In the ideal world, all parties and the simulator can only communicate with the functionality and the environment.
- In the real world, who controls the non-corrupted parties?
What does "control" mean? Parties are just independent Turing machines, which process some input and then have some output. Therefore, they don't have any input on their own, and they are activated by the environment, usually after the environment gave them some correct input.
- In the hybrid worlds, who controls the non-corrupted parties? Are they the worlds that exist both simulators and adversaries? Who else exists in those worlds?
Not really. A hybrid argument is, that you have some other functionality $F_{other}$, which is realized by $\Pi_{other}$ (in the UC framework). And then you actually use $\Pi_{other}$ in the real world, while using $F_{other}$ in the ideal world (both where they belong). Since they are already proven indistinguishable for the environment, you can use them for your own proof in their respective worlds. Basically, this is just the composability of the UC framework.
For some further reading:
The UC approach: an application view
