Estimate wrong?

I have a case where the dev task estimate is wrong, can it be changed during the sprint?

Yes. The Sprint Backlog should tell the truth at all times about how much work is currently believed to remain.

In this case, the task is 3 points and the dev calculates it to 8 points, can I tell the dev to break it into smaller tasks under 3 points?

No, you can't tell a Developer to do anything. To do so would be disrespectful. You can remind the Developers of their Sprint Goal commitment, and help them to renegotiate scope so the Goal can be met by work that is Done.

I have a case where the dev task estimate is wrong,

No, you don't have a case.  The Scrum Team has a case.  And in fact, I would be surprised if this wasn't a situation all the time.  Estimates are guesses made based upon the information known at the time you make that guess. When work begins, it is not uncommon to uncover new information that could affect your original guess.  

I question why it matters to update the guess if work has already begun? At that point the estimate is no longer valid. And if you start updating the estimates to reflect reality, then you are not able to use estimates anymore.  "But what about our velocity?".  Velocity isn't about how much work you guess you can do, it is about how much you are historically capable of doing on a consistent basis.  So if you try to plan based upon a guess you made and compare that to actual effort, you are comparing apples to chicken legs because they are two completely different things.

I suggest you just leave the estimate/guess alone, get the work done and then encourage the team to discuss why the original estimate was off so that they can improve their estimation abilities. 

And +1 to @Ian's response to your second question.  As a Scrum Master you don't tell anyone what to do.  You help them recognize when something that is being done is counter to the goal and then facilitate the learning on how to improve. 

What is the value in changing the estimate or artificially breaking the work into smaller tasks? I don't see one. Depending on how the Developers organize their Sprint Backlog to give stakeholders visibility, then perhaps decomposing it into smaller tasks would be good, but that would be standard practice unrelated to the estimate being off from the actual. Once you've planned the Sprint by crafting a Sprint Goal and selecting Product Backlog Items for the Sprint Backlog, the estimate doesn't have that much value anymore, so I don't really see a need to go changing it.

I'd also be very careful about telling Developers to do things, especially when it comes to the Sprint Backlog. The Developers are the owner of this artifact and can manage it any way they see fit. If you have suggestions to help the team along, then maybe you can think about bringing it up at the Sprint Retrospective. Generally, though, I'd recommend letting the Developers manage their Sprint Backlog on their own until they explicitly ask for help.

Thank you @Lan Mitchell @Daniel Wilhite @Thomas Owen

Question 1, I agree

Question 2, I explain my company's Scrum Team process, my boss (PM) requires that user story or tasks be broken down as much as possible, up to 3 points or less, so that the development team can be seen. Deploy done daily tasks, don't let 1 task last for many days. But now when estimating, my team has a difficult problem that when scoring for the task, it must include the time of QC inspection, I don't know if you can help me with this process.

Estimates should only count the time the dev does the work, not the time for the QC, or the time the QC checks.

Estimates are estimates. If you are not billing on the base of the estimates, I wouldn't invest time into changing and would exclude it from the story baseline.

But you can address it in the retro to improve the estimation process.