Ensuring accuracy of story points

How can a scrum master ensure that the story point estimates are more or less accurate?

How can he/she ensure the team is not overestimating or underestimating as either of them affects the sprint planning

You can't - that is the short answer.

If we could get such accurate numbers, then it wouldn't be an estimate right? A Development Team may over or under estimate, however, the key is to bring transparency over the matter and use the learning to optimize how you estimate in the future.

I agree with Steve. It is just estimated effort, not exact amount of time that they will spend on the work. 

Why would you like to ensure if team is not overestimating or underestimating? If it will happen, the Development Team should notice it during the Sprint because they will either have too much work or not enough for the Sprint. The reason why effort is estimated, not planned with 100% accuracy is because conditions are changing. There is always possibility that Development Team discovers some additional work required that they couldn't predict at the beginning of the Sprint. 

Scrum Master should support the team in tracking their daily progress what will help them to notice any estimation issues. Remember that story points estimation is for the Development Team to track their progress and measure velocity. It definitely should not be used to any other controlling purposes.

How can a scrum master ensure that the story point estimates are more or less accurate?

How can he/she ensure the team is not overestimating or underestimating as either of them affects the sprint planning

Why do you need to ensure this at all? Doesn't the team learn to get better at estimation, so planned Sprint Goal commitments are met? If not, why not? What are the consequences?

I agree with what has been shared in here: you cannot.

The story points is a way the team can estimate the complexity of each item. Estimations are, by definition, just a rough approximation.

The teams will do their best estimating the items, and as a scrum master the best you can do is to facilitate a conversation during the retrospective for them to inspect if their approximation was good enough or if they need to adapt the approach they are taking based on the outcome of the sprint.