Q:

How to handle and engage employees in a secretive company culture?

Senior management in my company discourages revealing strategic and management decisions to first line employees. Since I have joined the ranks, I have been told that employees should just worry about doing their job. I am not sure whether this is the practice everywhere, but I think the reason is because our business is a pioneer in its field and wants to avoid leaks at all costs.
As a new manager, I sometimes find myself being pushed by my subordinates to make decisions I cannot make until I consulted, or to explain to them information that is hard to make believe - or that I don't know either. So very often it seems like I am just ignorant and not listening to their advice/suggestions.
Typical Conversation
Employee:"Shouldn't we use this technique in this project?"
I:"Oh, that sounds good, but the policy is we shouldn't.."
Employee:"Oh please come on, even you know that this is the most appropriate. We can all see."
Sometimes what my employees say makes more sense because it is actually backed by logic or data, whereas senior management just gives us strategy without a very clear explanation.
This obviously makes employees feel less motivated and involved in decision-making process.
However, I would like to be a good manager... how can I turn this situation into something better and make the work environment and motivation blossom?
In response to the comment:
I don't think I have any influence at company level, so I am asking about how to keep the employees positive and engaged with their work in spite of the existing corporate culture.

A:

Executive Summary

how can I turn this situation into something better and make the work environment and motivation blossom?

You can't.
Not all employees are fit for every company culture. Your job as a manager is to clearly explain constraints, and the employees need to find how to work effectively given those constraints.
Constraints
Not everyone is cut out for every job. Someone with a strong sense of ethics may not be cut out to be a used car salesman. Someone with a strong sense of pride in their work may not be cut out for work in a firm trying to make a quick buck and get out. Someone with a strong desire for job security may not be a good fit for a startup.
Jobs are like relationships -- you need to find one you like, not assume you can change it to match your fancy after the fact.
A good organization will make these constraints obvious from before the process even begins. I don't think anyone joining the military imagines that they will have a flat management structure for instance. Ideally your company will make the constraints for developers clear during the interview process.
Explaining Constraints
If not, your job is to make sure that they are clear. For instance, you could call together your employees and say something like:

I understand that sometimes you want more details on why a decision is made. As you know, this company deals with a lot of proprietary technology, and often times the details on why a decision is made cannot be shared. I appreciate your desire to understand more, and at the same time I would like you to understand that there are times I cannot share the reasons with you.

Your employees should understand that there are things that you cannot/will not tell them. That it is their job to accept the information you provide, complete or not, and to work within the parameters that they are instructed to work in.
Watch Your Attitude
You seem to be implying that you disagree with your management. Here are some examples:

"Sometimes what my employees say makes more sense because it is actually backed by logic or data, whereas senior management just gives us strategy without a very clear explanation."
"This obviously makes employees feel less motivated and involved in decision-making process."
"how can I turn this situation into something better and make the work environment and motivation blossom?"

Your job as a manager is to make your employees work within the constraints decided by your managers. Implying to your employees that you agree with them will undercut not only your authority, but the authority of your managers. This will impact their ability to do the work in the manner the company has decided it should be done. If you disagree, you need to speak to your management, not subvert their authority.
Discuss with Your Management
Since it seems that you side with your employees and disagree with your management. While making your employees work within the constraints you are given, you can address their concerns the proper way, directly to your management. Realize, however, that if the company culture promotes secrecy/confidentiality, bringing up any concerns regarding that policy may paint you as someone who isn't a 'team player' or who can't get the job done.
If you think the impact on the productivity/motivation of your employees is of serious concern to the company (and not just an, "it'd be nice if..." sort of thing), then you should bring it up to your manager within the context of the company goals. For instance:

Hey boss, our company is constantly discussing the importance of customer satisfaction through high quality. Currently my developers are struggling delivering the appropriate level of quantity because the technologies they can use are limited and not well defined. For instance, on this project we were limited to using language X. Feature A can be implemented incredibly easy with technologies Y or Z, but requires a month of time to implement in language X. Without being able to explain why we can't use Y or Z, the employee is limited to creating the workaround in language X at the expense of time and quality.
While I understand that confidentiality, especially in regards to larger architecture decisions is incredibly important to the company, being able to give the developers a clearer understanding of the constraints and why they were made will allow them to find better solutions to problems saving time and increasing quality. Is there any way we can either have one of the people responsible for the decisions to be available for questions when the new project kicks-off, or to have someone to be able to contact in situations like this?

The key points here are:

The goal is to achieve company objectives
The current method has concrete reasons it isn't ideal for your employees
Giving constructive suggestions on how to limit the issue

A:

When you say "the policy is we shouldn't" you think you're saying "so stop bugging me to do it" but they hear an invitation to rebut: "the policy is dumb then, can't you get it changed?"
I recommend an answer that contains more of the truth, such as these:

there are factors involved that I can't discuss with you. They rule out that technology.
while it might appear on the surface to be a good choice, I have reasons for not using it
people who know the whole picture, including some confidential aspects, have eliminated that technology from consideration

This may invite some people to pester you for details or to gossip, but it will at least stop them pushing at you to do something you know you can't do. 
I ran into a great example of this very recently. A client has sold their product, built with tech A from company B, to company C, a direct competitor of B and a known B-hater. They actually required a waiver signed by someone-you've-heard-of at C to allow them to install A libraries (from B) on C servers. It's a big deal, worth a lot of money to them. They have actually been told to make a B-free version of their product, and that if anyone else offers a B-free version first, they'll be replaced. Imagine you worked there, and you were told to port your perfectly good A-based solution to a D-based solution (where D is made by C or at least someone C doesn't hate.) You might push back. You might say A is way better for this - and you might be right - but you will still have to build it with D, like it or not. A manager in this situation cannot start blurting out about C and how they hate B and what someone-you've-heard-of said - this stuff is all confidential. But carefully alluding to the fact it exists should help logical developers accept reality and starting working on that D version.
I find it helps my mental health to always assume such things are happening when I am given illogical instructions, but not everyone does that. So to the extent you can, don't just say "that's the policy" but left the curtain a little that there is a reason, just not one that can currently be shared. Over time, people may come to trust that you are not illogical even when you have to be more secretive.

A:

I've worked in big, tightly controlled companies most of my career, and I have to say that I've rarely found this to be the reason people leave a company, though it's often a factor to dissatisfaction.  But it sounds like you may have even tighter constraints.
Here's some general stuff that's worked in big company environments.
Separate the Technical Domain and the Business Domain
To the greatest extent possible, separate the technical domain and the business domain.  The business domain is "what are we trying to do as a strategy" and "how does the business need this to work for our model to be successful" - those may well be within your upper management's realm of tight control, and you'll have to rely on interactions with superiors to coordinate the work of your team and these closely held secrets.
The technical domain is "how are we going to get that stuff done?" - and that's the area where you may have some negotiating room. In most technical work, most sane people will admit that the team doing the work can be the experts on exactly the work gets done.  In every case, do what you can in discussions with upper management to angle for requirements as technologically agnostic ideas, and not "use this application" or "don't use this application".
For example:

configuration management - what areas need configuration management, and what checks and balances need to be in place.  Not - what configuration management system should we use, or never ever changing the process
implementation decisions - what's the requirement, not use X to fullfill this requirement.

There's areas where this can be impacted by the business.  For example, if the company's made a deal with a client to use a specific implementation, or if there are fairly secretive security concerns in a given area.  But this upper level minute decisions making can become a habit, that can be gently persuaded away if you've got enough trust with your own management.
Know the Constraints
If your team is dealing with a particularly atrocious way of doing something and management simply won't budge, argue to change other aspects of the work.  If it'll take longer, or cost more, make that clear.  Offer the better way as one option, but be prepared with time estimates for what it'll take to do it their way.  If upper management insists on controlling certain decisions, it's your job to arm them with the facts of what those decisions imply.
This is a time where you can engage the people on your team. No matter how dumb they may think the dictated approach may be - ask them to qualify that statement of "this is dumb" with a time estimate.  I often phrase it as - "give me the tradeoff between your way and the company way" - get the estimates and costs to change to a better way and the comparable options for doing it the company way.  I've seen the research come out both ways - there's been many a time when I win this argument on the team by making the team themselves consider the TOTAL cost of the change...  With that said, I've also won in the other direction - presenting a case to management that engineering can find a better way.
The trick here is that you can't ever promise change in an organization like this.  Your promise has to be that you'll advocate for the team's ideas and give credit where credit is due.  But you can't promise what you yourself don't control.
Sometimes that's just the way it is
In any really tightly controlled organization, there is a "that's just the way it is" effect.  You hope that they aren't too entrenched in too many fixed ideas - but how much is too much is an essentially individual choice.
In certain companies you just have to suck it up and say "they are paying my salary so I'm doing it their way".  At some point, you may find enough of these that it's no longer worth it, and that's when it's time for a job hunt.  
But there's also a spectrum of individual and you want to be aware of this in hiring decisions.  If you are hiring someone who runs very far to the "I like to do things MY way, and I won't do things that are dictated by authority if I can't justify them to myself" side of the spectrum, you may not have a good personality match.

