Is a board required by Scrum?
Kind of a theoretical question. Does Scrum require using a board? Can I use Jira Scrum project without a board at all?
No. Scrum does not require a Kanban-style board of any kind. You should generally use one anyway, though, for the reasons explained below.
Scrum requires an ordered Product Backlog managed by the Product Owner, and a Sprint Backlog managed by the Development Team. The format, contents, and processes for managing the backlog items are implementation details that are up to the Scrum Team to work out for themselves in accordance with the principles of Scrum and the Agile Manifesto.
You commonly see kanbans in Scrum because Scrum theory values transparency and visibility to aid the inspect-and-adapt cycle. Physical or virtual boards help to visualize the work, and so this practice is commonly borrowed from Kanban and related frameworks. However, the Scrum framework is not highly prescriptive, and so the use of such boards is widely considered a best practice but not a framework requirement.
The Scrum Team is free to represent the Product and Sprint backlogs in any way that the team finds effective. The team can also radiate information about the status of the project in any way that it sees fit so long as it supports the necessary empirical control feedback loops on which the framework is based.
Why You Should Use Physical or Virtual Boards Anyway
With all that said, physical boards are often simpler to use, and encourage face-to-face collaboration more than virtual boards. Tools like JIRA often constrain the process needlessly, and often add unnecessary complexity rather than supporting the Scrum Team's self-managed processes. Tools should support processes, not dictate them!
Software-based boards are often a good option when a team isn't geographically co-located, or when the chosen tool provides automations that free up the team from what might otherwise be a very manual task. In most cases, choosing a tool before defining a process is an anti-pattern. If you can't represent your workflow on a simple corkboard, it's likely you have process or implementation problems that software can't fix for you.
Finally, not having a board at all (whether physical or virtual) is probably unwise unless the Scrum Team is experienced enough to meet the framework requirements in some other clearly-defined way. Common practices are common for a reason; deviate from them when necessary, but don't create unnecessary project risk by wandering off a blazed trail without a very good reason. Kanban-style Sprint Backlogs are widely used because they're effective, so don't forgo the use of a visual board unless you really know what you're doing and why.